There haven't been any changes to the fts1 code! Your best bet is to put together a .c file with a main() which causes the problem. Or a tcl script, or anything that would allow someone to see things locally. The problem right now is that there's no particular way for any of us to find the problem, short of making educated guesses and experimenting, which implies many hours of work. If I had a main() that caused the problem, I could run the test locally and determine if it happens to me, then I could spin it up in the debugger and likely narrow things down rather quickly.
-scott On 1/12/07, ohadp <[EMAIL PROTECTED]> wrote:
It returns 3 (text) both before and after the update. I bet someone who's familiar with fts1 code would immediately spot the change that caused this encoding bug Dan Kennedy-4 wrote: > > On Thu, 2007-01-11 at 15:00 -0800, ohadp wrote: >> here's the detailed description of the apparent bug: >> >> i'm using the _16 versions for getting text from an fts1 table. >> if i insert data and select, i get good data, meaning my call to >> sqlite3_column_text16(..) returns a pointer to a UNICODE string. >> if i update and then select, my call to sqlite3_column_text16(..) returns >> a >> pointer to an ASCII string instead of a UNICODE one. The string if >> interpreted visually is the right string, but calling the unicode version >> of >> the function and receiving an ascii string is a problem :-) > > What does sqlite3_column_type() return? I'm wondering if it will be > SQLITE_BLOB. > > Dan. > > > >> ohadp wrote: >> > >> > The precompiled binaries... work :-) >> > i stepped in and it seems like the problem is an ascii/unicode problem. >> > what happens is that i call sqlite3_column_text16 and get back an ASCII >> > string... >> > i haven't touched the rest of my code so let me ask if something's >> changed >> > in this latest release ? >> > >> > >> > Scott Hess wrote: >> >> >> >> On 1/11/07, ohadp <[EMAIL PROTECTED]> wrote: >> >>> Scott Hess <[EMAIL PROTECTED]> writes: >> >>> > CREATE VIRTUAL TABLE t USING fts1(content); >> >>> > INSERT INTO t (rowid, content) VALUES (1, 'this is a test'); >> >>> > UPDATE t SET content = 'that was a test' WHERE rowid = 1; >> >>> > >> >>> > -- The following is returning 'gibberish here' for me: >> >>> > SELECT content FROM t WHERE rowid = 1; >> >>> >> >>> I'm using the latest version available for download on the sqlite >> site, >> >>> 3.3.10. >> >>> Compiling on Windows with MSVC (2003). >> >>> I tried the script you provide and I get gibberish. >> >>> To be sure I selected the data before the update and it comes back >> >>> correctly. >> >> >> >> Odd, it works fine for me (compiling from CVS head on Linux). I just >> >> downloaded the 3.3.10 tarball and recompiled from scratch (again on >> >> Linux), and it also works fine. >> >> >> >> You're compiling it? Have you tried running the pre-compiled Windows >> >> binaries? [I'm only assuming that fts1 is available in there somehow >> >> :-).] >> >> >> >> -scott >> >> >> >> >> ----------------------------------------------------------------------------- >> >> To unsubscribe, send email to [EMAIL PROTECTED] >> >> >> ----------------------------------------------------------------------------- >> >> >> >> >> >> >> > >> > >> > > > ----------------------------------------------------------------------------- > To unsubscribe, send email to [EMAIL PROTECTED] > ----------------------------------------------------------------------------- > > > -- View this message in context: http://www.nabble.com/3.3.10-data-corruption-on-updating-fts1-string-table-tf2960926.html#a8296459 Sent from the SQLite mailing list archive at Nabble.com. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
