Re: [sqlite] how can i speed up inserts ?
what about the differences between the FULL and PARTIAL modes of pragma synchronous ? -- View this message in context: http://www.nabble.com/how-can-i-speed-up-inserts---tf3186848.html#a8860860 Sent from the SQLite mailing list archive at Nabble.com. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] how can i speed up inserts ?
when you say much less do you mean one in 1,000 or 1 in 1,000,000 ? Gerry Snyder-3 wrote: > > If you really can't get more than 4-5 in a batch, it's your call whether > the time saving is worth the risk. BTW, the problem rate should be much > less than one in ten thousand. > > Gerry > > - > To unsubscribe, send email to [EMAIL PROTECTED] > - > > > -- View this message in context: http://www.nabble.com/how-can-i-speed-up-inserts---tf3186848.html#a8856637 Sent from the SQLite mailing list archive at Nabble.com. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] how can i speed up inserts ?
luckily this isn't mission critical failure, i'll take the risk that one out of ten thousand users experiences database corruption. i can only batch the inserts into maybe 4-5 a time, don't know how much of an improvement that will be... Dennis Cote wrote: > > ohadp wrote: >> holy smokes that pragma just made my several hundred inserts take half a >> second compared to 30 seconds earlier. >> >> thanks! >> >> > Yes, but now your database can be corrupted by a power failure or OS > crash. > > Wrapping several hundred inserts in a transaction will be nearly as fast > and completely safe. > > HTH > Dennis Cote > > - > To unsubscribe, send email to [EMAIL PROTECTED] > - > > > -- View this message in context: http://www.nabble.com/how-can-i-speed-up-inserts---tf3186848.html#a8849056 Sent from the SQLite mailing list archive at Nabble.com. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] how can i speed up inserts ?
holy smokes that pragma just made my several hundred inserts take half a second compared to 30 seconds earlier. thanks! DragonK wrote: > > On 2/7/07, Ohad Eder-Pressman <[EMAIL PROTECTED]> wrote: >> >> i've got sqlite compiled with visual-studio, with all the default >> options, >> didn't touch anything. >> inserts are just a bit too slow for me, is there a good way to speed this >> up >> using some flags ? >> any other flags that it would be smart to turn on for some better >> performance ? > > > > Try using transactions for an insert and turning off synchronization via > Pragma synchronize. > > See here: http://web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html > > > thanks >> > > > > -- > ...it's only a matter of time... > > -- View this message in context: http://www.nabble.com/how-can-i-speed-up-inserts---tf3186848.html#a8845264 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
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, &vm, 0);
>> sqlite3_step(vm);
>> sqlite3_finalize(vm);
>> }
>>
>> void exec_query(const TCHAR* cmd)
>> {
>> sqlite3_stmt* vm;
>>
>> sqlite3_prepare16(db, cmd, -1, &vm, 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"), &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
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, &vm, 0);
sqlite3_step(vm);
sqlite3_finalize(vm);
}
void exec_query(const TCHAR* cmd)
{
sqlite3_stmt* vm;
sqlite3_prepare16(db, cmd, -1, &vm, 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"), &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
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
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
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
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#a8288183 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
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
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] -
