On Mon, Apr 4, 2011 at 6:43 AM, Enrico Thierbach <e...@open-lab.org> wrote: > Is this really a bug? I at least wouldn't expect last_insert_rowid to be > constant if the database gets modified.
If you read the post that Simon referenced you'll see that the caller typically wants to know the row ID of the last row explicitly inserted by the caller. OK, that was implied in that post. However, there are oddities w.r.t. this function. What of INSERTs into VIEWs with INSTEAD OF triggers that don't actually insert anything? Then there's the re-entrance issue we have in this case. I tend to thing that last_insert_rowid() is best avoided because it's an optimization (no need to run a query to find what your last statement did) that is not needed if you manage your primary keys directly (i.e., don't rely on the RDBMS to do autoincrement or any other form of primary key allocation). In any case, last_insert_rowid() seems particularly difficult to get right, though D. R. Hipp seems to be getting at a reasonable implementation and semantics: last_insert_rowid() returns the row ID of the first row inserted by the last statement other than the currently executing one at the same level of re-entrance. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
