-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> can you please re-open the ticket? This bug only occurs in >> combination with FTS3. Using normal tables in triggers does not cause >> any problems.
The underlying cause is that FTS3 has several other tables (use .dump to see them) that store its underlying data. So when you do an operation against FTS3 it then does one or more operations against those backing tables. That is why you are getting the "wrong" id. To fix this requires that the FTS3 code remember the insert id, do its remaining operations and then set the last insert id back to the remembered one. However there is no API for doing that. (It may also be possible to re-order the operations done by FTS3 so the right id comes out in the end.) Anyway I am not on the SQLite team and have only been doing janitorial work on the old bug tracker. Anyone who cares about this issue needs to convince the SQLite team that this is an issue (ie the FTS3 specification is that last insert row id should work) and consequently will need to be fixed (code rearrangement, adding a new SQLite API). Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrkjxQACgkQmOOfHg372QQ1wACguE26dPFyrFLmpYb36Cp/1mi+ yzIAnjBKA+aTiJy4Crqg0AxiCnqBl9b5 =V9Z5 -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
