On May 22, 2008, at 3:10 PM, Dennis Cote wrote: > Bram de Jong wrote: >> >> I have found a bug which happens in both FTS2 and FTS3. >> >> The bug happens when a trigger updates an FTS table: the insert ID >> gets trashed: >> > I think both Richard and Scott may have misread this one a little bit. > > It seems to me that all the operations Bram has done are using the > normal (i.e. non-virtual table) table, one. All the accesses of the > virtual table search are done inside the trigger routines. SQLite is > supposed to be saving and restoring the last_insert_rowid value for > each > trigger execution context. These operation should work as expected > regardless of what is done inside the trigger. An update of a normal > table should not be changing the last inserted rowid value. > > Perhaps the problem is simply that the update trigger is not doing the > save and restore operation correctly. In any case it looks like > there is > a real problem here.
I think the FTS virtual table is doing the INSERTs inside its xCommit method, after the trigger has been exited. So the mechanism that resets the last_insert_rowid when a trigger exits does not apply since the trigger has already existed by the time the FTS virtual table does its INSERT. (NB: I have not verified this in a debugger - it is just my theory.) D. Richard Hipp [EMAIL PROTECTED] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
