Okay I know very little about these things, but the fact that Access/JET MDB files are serverless (it's just a bunch of Windows dll's) in the same way as SQLite, and that JET implements row and table level locking means I guess it is possible.
If it meant losing ACID compliance, then no, forget about it, but if it meant much bigger database files, then no problem, as long as the row level locking could be turned on or off at compile time (i.e. those who don't care about row level locking, but do care about file size can compile without it). So if it can be implemented by storing a lock record for every row that is about to be updated in a new system table, then why not? Of course row level locking will make updates slower, but you can't have fine grained locking and ultimate performance. As I say, if it could be implemented knowing that: 1. Performance will be slower. 2. Database size will be bigger. 3. Row level locking can be compiled in or out. Then I think the majority of users would want the benefit of increased write concurrency, even at the expense of speed or database file size. -- View this message in context: http://www.nabble.com/SQLite-Vs-VistaDB---Comparison-----t1797052.html#a4902745 Sent from the SQLite forum at Nabble.com.
