> -----Original Message----- > From: sqlite-users-boun...@mailinglists.sqlite.org [mailto:sqlite-users- > boun...@mailinglists.sqlite.org] On Behalf Of R Smith > Sent: Tuesday, June 28, 2016 7:33 AM > To: sqlite-users@mailinglists.sqlite.org > Subject: Re: [sqlite] How to use "cursors" in c# > > > > On 2016/06/28 12:17 PM, William Drago wrote: > > > >> I am programming in c# and I have to insert into a .sqlite file a new > >> row and get back the id of this last inserted row. This file > >> "unfortunately" > >> might be located on an internal network and other users might try to > >> add other rows in the meantime. > > > > > > I can't help with your locking issues, but if you are using the > > System.Data.SQLite ADO.NET provider in your C# program you can get the > > ID of the last row inserted with the LastInsertRowID property of your > > connection like this: > > > > > > long rowID = connection.LastInsertRowId; > > > > I use it after I commit the transaction. > > Oh that's dangerous (sometimes) - it is possible for a second > process/application/DB connector to insert a row in between you closing the > transaction and reading the rowID so that it is no longer the last row id... > which is fine if you simply use it to record a relationship to the inserted > data > in another place, but problematic if you use it to guess/force the id of the > next row to be inserted (probably in some next transaction that might be a > mile away). > > Of course, in 99% of applications (as in applied instances, not programs), > this > is unlikely to ever be a bother, but it's that other 1% that causes 80% of the > fails in real life[1], so it pays being diligent. > > Thus, I'll add my voice to those forewarning Martina - it is best to retrieve > the > next row ID to be inserted (or whatever value/field you use for primary > keying) within a transaction before the next inserts (which should all happen > inside that same transaction). That way can never[2] fail. > > > Cheers! > Ryan > > > [1]: Probably not 80% exactly, this figure is intended to illustrate the > principle, > and doesn't claim to be empirical. > [2]: Again, "never" is used here approximate to the principle. In real life, > bugs > happen. :) > >
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. -- Bill Drago Staff Engineer L3 Narda-MITEQ 435 Moreland Road Hauppauge, NY 11788 631-272-5947 / william.dr...@l-3com.com CONFIDENTIALITY, EXPORT CONTROL AND DISCLAIMER NOTE:This e-mail and any attachments are solely for the use of the addressee and may contain information that is privileged or confidential. Any disclosure, use or distribution of the information contained herein is prohibited. In the event this e-mail contains technical data within the definition of the International Traffic in Arms Regulations or Export Administration Regulations, it is subject to the export control laws of the U.S.Government. The recipient should check this e-mail and any attachments for the presence of viruses as L-3 does not accept any liability associated with the transmission of this e-mail. If you have received this communication in error, please notify the sender by reply e-mail and immediately delete this message and any attachments. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
