Sorry for the delay. CVS change 3596 fixes this problem for fts1 and fts2.
-scott On 1/12/07, Scott Hess <[EMAIL PROTECTED]> wrote:
http://www.sqlite.org/cvstrac/tktview?tn=2166 I'm probably not going to be back on this until Monday or Tuesday, unfortunately. -scott On 1/12/07, Scott Hess <[EMAIL PROTECTED]> wrote: > [Find attached the file I'm using to debug this.] > > I think I've found the difference causing this, but I don't understand > why it matters. It all should apply to fts2, the code in question > didn't change in a way likely to change this. > > When an insert is done against an fts1 table, index_insert() is called > with the list of sqlite3_values passed in from sqlite code, which in > turn calls content_insert() with those values, which runs an insert > statement binding each value to the appropriate parameter. Then > index_insert() calls insertTerms() to tokenize the data and insert the > terms into the fulltext index. > > When an update is done, index_update() is called with the list of > sqlite3_values. Here, it calls insertTerms() to insert the terms into > the fulltext index, then content_update() to write the data into the > content table. > > The important point is that insertTerms() calls sqlite3_value_text() > on the values. This call appears to destructively convert a > UTF16LE-encoded value to a UTF8-encoded value. So, on insert the > values bound are UTF16 values, while on update the values bound are > UTF8 values. > > At this time I don't understand why this would be the case, I would > expect sqlite to convert things as needed (the enc variable in the > sqlite3_value _appears_ to be correct). But, indeed, if I rearrange > the calls to insertTerms() and content_update() in fts1.c > index_update(), things work as expected. > > -scott > > >
----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
