On 2015-04-01 07:10 PM, Kumar Suraj wrote: > Hi Richard.. this wont work for me due to following reason. > > If a separate thread performs a new INSERT > <https://www.sqlite.org/lang_insert.html> on the same database connection > while the sqlite3_last_insert_rowid() > <https://www.sqlite.org/c3ref/last_insert_rowid.html> function is running > and thus changes the last insert rowid > <https://www.sqlite.org/lang_createtable.html#rowid>, then the value > returned by sqlite3_last_insert_rowid() > <https://www.sqlite.org/c3ref/last_insert_rowid.html> is unpredictable and > might not equal either the old or the new last insert rowid > <https://www.sqlite.org/lang_createtable.html#rowid>.
Yes... this is why transactions exist and why multiple connections used by multiple threads is safe - there is no such thing as unpredictable inside an ACID engine transaction. The last row id will remain valid for the duration of the transaction. Outside of a transaction any writer can update any row/table at any time and produce very many different row id's due to inserts. How did you intend to control the last insert concurrency in your application? If you explain the rules you have set for your application, we can tell you how to get sqlite to play ball. Also - if you do actually use AUTOINCREMENT as opposed to simply an integer primary key, you can look up the next AI number in the sequence from the sqlite_sequence table you will find auto-created in your DB (which is where sqlite gets it too) and yet another way is to query the MAX(rowid) of the table (this will be slower) - All of this however must also happen inside of the same transaction (as the insert) to be meaningful.
