On 2016/06/28 5:10 PM, Drago, William @ CSG - NARDA-MITEQ wrote:
Ah, good thoughts. My thinking was that the last row id wouldn't be valid until the transaction was successful. But I guess if the transaction is not successful it doesn't matter what the last row is because now there are different problems to deal with.
For some extra information - I don't ever use the last_insert_rowid (or its ilk in other RDBMS systems) so I might not be 100% accurate in this next statement (Someone please correct it if I'm wrong), but I believe the last_insert_rowid in SQLite will always be updated directly with the INSERT succeeding, and so after every successful INSERT should have the value of the row_id that was added in that specific INSERT's case - whether during a Transaction or not, but obviously bound to the connection making the Inserts.
I am not clear on what happens for INSERT OR REPLACE results when a row gets updated in stead of inserted, but the documentation should have details.
As an aside - I've always prescribed generating your own ID's. There is no requirement for using AUTOINCREMENT in any DB - It's a lazy method for creating an easy sure-to-be-unique ID list for simple inserted rows, and brilliant for stuff like log files or such, but I would make effort to avoid it where one can manage the IDs another way. Palming that responsibility off to the DB engine is surely easier, but less optimal, if only in more complex and foreign key designs.
_______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
