On Thu, Jan 07, 2010 at 11:25:28AM -0500, Pavel Ivanov scratched on the wall: > > ?At the very least, do the initial INSERT and get-last in a > > ?single transaction. > > Not necessarily. You can do INSERT and get-last without starting > transaction because get-last is per-connection, not per-database. So > the only thing that should be taken care of is no inserts are executed > on the connection between your initial INSERT and get-last.
True. An SQL transaction isn't strictly required, but it still strikes me as prudent. You definitely want to do it as an "application transaction," in the sense that if you have a threaded application, the sequence of calls needs to happen within a single lock/release sequence over the database connection. But an SQL transaction is not actually required. > > ?Also be careful with triggers. ?Triggers can muck everything up by > > ?changing the "last." > > Also false. Triggers don't change the value returned by last_insert_rowid(). They do if you're inside the trigger. And can then change the value returned again, just by exiting. My intention with that statement was to say "be careful of your context because this function and triggers interact in ways you might not expect." Looking at it now, I see my choice of words was not very clear. You are quite correct that, when an INSERT (even with triggers) is all said and done, the value returned by last_insert_rowid() is the one you'd expect. I didn't mean to imply otherwise. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Our opponent is an alien starship packed with atomic bombs. We have a protractor." "I'll go home and see if I can scrounge up a ruler and a piece of string." --from Anathem by Neal Stephenson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
