> On 2/10/2012 9:57 AM, Sreekumar TP wrote: > >> The last transaction should always be the final one. In a a >> multiprocess/threaded application how can one make assumptions on the >> order >> of updates?
SQL does not have any concept of 'last transaction' or 'final transaction' or 'order of transactions'. Either a transaction is done or it isn't. There is no order for changes to a database done within a transaction. Either they're all done, or none are done. There is no idea that one change is made first, then another, then another. Similarly, if you specify an order in your SELECT command, that's the order you'll get the rows in. If you don't, the rows may appear in a random order. If you don't specify an ORDER BY clause or perhaps even if you do and your ORDER BY is ambiguous, they could easily appear in a different order every time you do a SELECT. On 10 Feb 2012, at 5:19pm, Sreekumar TP wrote: > Though the example of $ is very intuitive, I am not suggesting that we > drop one of the transaction and block the database forever (as it is > happening now). Instead, it could be serialized such that two $100 > transactions are committed to the db. You BEGIN one transaction. In that transaction you make the two changes which balance each other out. You COMMIT the transaction and both changes are made. Or you ROLLBACK the transaction and nether change is made. That's how transactions work. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
