Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
Glad I could help find something, hope I put you in the right direction with
the source sample.
In the meantime I've moved to standard tables due to other limitations
imposed by FTS1/2.
Scott Hess wrote:
>
> OK, there's definite meat, here. I have other reports of users seeing
> this problem. It's specifically related to doing UPDATE against an
> fts1 or fts2 table. INSERT and DELETE both work fine. As far as I
> can tell, UPDATE may have never worked, or may have worked only in
> specific circumstances. More as it's available.
>
> -scott
>
>
> On 1/12/07, ohadp <[EMAIL PROTECTED]> wrote:
>>
>> looks like the file came in without CRLF, here goes:
>>
>> --
>> #include "../sqlite-3_3_8/sqlite3.h"
>> #include
>>
>> static sqlite3* db;
>>
>> void exec_dml(const TCHAR* cmd)
>> {
>> sqlite3_stmt* vm;
>>
>> sqlite3_prepare16(db, cmd, -1, , 0);
>> sqlite3_step(vm);
>> sqlite3_finalize(vm);
>> }
>>
>> void exec_query(const TCHAR* cmd)
>> {
>> sqlite3_stmt* vm;
>>
>> sqlite3_prepare16(db, cmd, -1, , 0);
>> if (sqlite3_step(vm) == SQLITE_ROW)
>> {
>> TCHAR* result = (TCHAR*)sqlite3_column_text16(vm, 0);
>> result=result;
>> }
>>
>> sqlite3_finalize(vm);
>> }
>>
>> int _tmain(int argc, _TCHAR* argv[])
>> {
>> sqlite3_open16(_T("test.db"), );
>> exec_dml(_T("CREATE VIRTUAL TABLE t USING fts1(content);"));
>> exec_dml(_T("INSERT INTO t (rowid, content) VALUES (1, 'this is a
>> test');"));
>>
>> exec_query(_T("SELECT content FROM t WHERE rowid = 1;"));
>> exec_dml(_T("UPDATE t SET content = 'that was a test' WHERE rowid
>> = 1;"));
>> exec_query(_T("SELECT content FROM t WHERE rowid = 1;"));
>>
>> return 0;
>> }
>> --
>> --
>> View this message in context:
>> http://www.nabble.com/3.3.10-data-corruption-on-updating-fts1-string-table-tf2960926.html#a8305111
>> Sent from the SQLite mailing list archive at Nabble.com.
>>
>>
>> -
>> 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#a8312740
Sent from the SQLite mailing list archive at Nabble.com.
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
OK, there's definite meat, here. I have other reports of users seeing
this problem. It's specifically related to doing UPDATE against an
fts1 or fts2 table. INSERT and DELETE both work fine. As far as I
can tell, UPDATE may have never worked, or may have worked only in
specific circumstances. More as it's available.
-scott
On 1/12/07, ohadp <[EMAIL PROTECTED]> wrote:
looks like the file came in without CRLF, here goes:
--
#include "../sqlite-3_3_8/sqlite3.h"
#include
static sqlite3* db;
void exec_dml(const TCHAR* cmd)
{
sqlite3_stmt* vm;
sqlite3_prepare16(db, cmd, -1, , 0);
sqlite3_step(vm);
sqlite3_finalize(vm);
}
void exec_query(const TCHAR* cmd)
{
sqlite3_stmt* vm;
sqlite3_prepare16(db, cmd, -1, , 0);
if (sqlite3_step(vm) == SQLITE_ROW)
{
TCHAR* result = (TCHAR*)sqlite3_column_text16(vm, 0);
result=result;
}
sqlite3_finalize(vm);
}
int _tmain(int argc, _TCHAR* argv[])
{
sqlite3_open16(_T("test.db"), );
exec_dml(_T("CREATE VIRTUAL TABLE t USING fts1(content);"));
exec_dml(_T("INSERT INTO t (rowid, content) VALUES (1, 'this is a
test');"));
exec_query(_T("SELECT content FROM t WHERE rowid = 1;"));
exec_dml(_T("UPDATE t SET content = 'that was a test' WHERE rowid =
1;"));
exec_query(_T("SELECT content FROM t WHERE rowid = 1;"));
return 0;
}
--
--
View this message in context:
http://www.nabble.com/3.3.10-data-corruption-on-updating-fts1-string-table-tf2960926.html#a8305111
Sent from the SQLite mailing list archive at Nabble.com.
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
looks like the file came in without CRLF, here goes:
--
#include "../sqlite-3_3_8/sqlite3.h"
#include
static sqlite3* db;
void exec_dml(const TCHAR* cmd)
{
sqlite3_stmt* vm;
sqlite3_prepare16(db, cmd, -1, , 0);
sqlite3_step(vm);
sqlite3_finalize(vm);
}
void exec_query(const TCHAR* cmd)
{
sqlite3_stmt* vm;
sqlite3_prepare16(db, cmd, -1, , 0);
if (sqlite3_step(vm) == SQLITE_ROW)
{
TCHAR* result = (TCHAR*)sqlite3_column_text16(vm, 0);
result=result;
}
sqlite3_finalize(vm);
}
int _tmain(int argc, _TCHAR* argv[])
{
sqlite3_open16(_T("test.db"), );
exec_dml(_T("CREATE VIRTUAL TABLE t USING fts1(content);"));
exec_dml(_T("INSERT INTO t (rowid, content) VALUES (1, 'this is a
test');"));
exec_query(_T("SELECT content FROM t WHERE rowid = 1;"));
exec_dml(_T("UPDATE t SET content = 'that was a test' WHERE rowid =
1;"));
exec_query(_T("SELECT content FROM t WHERE rowid = 1;"));
return 0;
}
--
--
View this message in context:
http://www.nabble.com/3.3.10-data-corruption-on-updating-fts1-string-table-tf2960926.html#a8305111
Sent from the SQLite mailing list archive at Nabble.com.
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
here's a file, plain.cpp, which demonstrates the problem.
if you're compiling on linux and not windows you'll have to do a few trivial
changes.
_T("string") is used to define a unicode string
TCHAR is WORD/SHORT/etc
Scott Hess wrote:
>
> 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
>
http://www.nabble.com/file/5610/plain.cpp plain.cpp
--
View this message in context:
http://www.nabble.com/3.3.10-data-corruption-on-updating-fts1-string-table-tf2960926.html#a8305058
Sent from the SQLite mailing list archive at Nabble.com.
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
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] -
Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
it looks like fts1/2 return an ascii string in disguise of a unicode string after an update to the data. John Stanton wrote: > > In that case your problem will be in your code, specifically in the > function which gives you a pointer to the data. > > Show us your code. > > ohadp wrote: >> i'm linking with it and calling the api directly. >> i think that sqlite3.exe doesn't have fts1 support in it. >> >> >> John Stanton wrote: >> >>>How are you calling Sqlite? Have you tried sqlite3.exe? >>> >>>ohadp 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; > Hi Scott, 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. >>> >>> >>>- >>>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#a8300239 Sent from the SQLite mailing list archive at Nabble.com. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
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] -
Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
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] -
Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
I'm not using the various 'bind' calls but simply executing SQL inserts/updates/querys with _sqlite3_prepare, _sqlite3_step. notice that the insert comes through as unicode, the update is recognized as unicode but stored as ascii. i looked into the code one level deeper and it looks like the storage in memory (sqlite3_value) has an 'encoding' property. the encoding is set to 2 (unicode), but the string is an ascii one. this worked for me in 3.3.8, didn't try 3.3.9. Scott Hess wrote: > > Are you absolutely, positively certain that you're calling > sqlite3_bind_text16() when setting up the update? I ask because I > recently spent a long afternoon tracking down that basic mistake :-). > > -scott > > > On 1/11/07, ohadp <[EMAIL PROTECTED]> 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 :-) >> >> >> >> 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] >> >> >> - >> >> >> >> >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/3.3.10-data-corruption-on-updating-fts1-string-table-tf2960926.html#a8288429 >> Sent from the SQLite mailing list archive at Nabble.com. >> >> >> - >> 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#a8288879 Sent from the SQLite mailing list archive at Nabble.com. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
This is happening only with FTS1. With a normal table everything comes back normally. 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 :-) > > > > 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] >>> - >>> >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/3.3.10-data-corruption-on-updating-fts1-string-table-tf2960926.html#a8288703 Sent from the SQLite mailing list archive at Nabble.com. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
Are you absolutely, positively certain that you're calling sqlite3_bind_text16() when setting up the update? I ask because I recently spent a long afternoon tracking down that basic mistake :-). -scott On 1/11/07, ohadp <[EMAIL PROTECTED]> 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 :-) 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] >> - >> >> >> > > -- View this message in context: http://www.nabble.com/3.3.10-data-corruption-on-updating-fts1-string-table-tf2960926.html#a8288429 Sent from the SQLite mailing list archive at Nabble.com. - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
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 :-) 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] >> - >> >> >> > > -- View this message in context: http://www.nabble.com/3.3.10-data-corruption-on-updating-fts1-string-table-tf2960926.html#a8288429 Sent from the SQLite mailing list archive at Nabble.com. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
In that case your problem will be in your code, specifically in the function which gives you a pointer to the data. Show us your code. ohadp wrote: i'm linking with it and calling the api directly. i think that sqlite3.exe doesn't have fts1 support in it. John Stanton wrote: How are you calling Sqlite? Have you tried sqlite3.exe? ohadp 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; Hi Scott, 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. - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
i'm linking with it and calling the api directly. i think that sqlite3.exe doesn't have fts1 support in it. John Stanton wrote: > > How are you calling Sqlite? Have you tried sqlite3.exe? > > ohadp 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; >>> >> >> >> Hi Scott, >> >> 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. > > > - > 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#a8285947 Sent from the SQLite mailing list archive at Nabble.com. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
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] -
Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
How are you calling Sqlite? Have you tried sqlite3.exe? ohadp 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; Hi Scott, 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. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] 3.3.10 data corruption on updating fts1 string table
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; > Hi Scott, 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. -- View this message in context: http://www.nabble.com/3.3.10-data-corruption-on-updating-fts1-string-table-tf2960926.html#a8285184 Sent from the SQLite mailing list archive at Nabble.com. - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] 3.3.10 data corruption on updating fts1 string table
inserts work once i update my fts1 table and then select data from it, i get gibberish. anybody seen something like this ?
