> In order to this, the next question ;-) Is a physcial Locking to the > DB allways necessary, if more the one User (writer) connect to a DB > and a Table? That means, is it insufficient, if I handle only a > logical Locking in the Application instead of physcial Locking?
As I understand it (mostly from reading this list, and a few side trips to the documentation), the way SQLite works during a database update is that the entire database file is locked, and remains locked until the update is complete. If you use transactions, the entire database file is locked for the entire transaction (*). Now, if there are multiple processes trying to update the same database file, only one can update it at a given moment. Attempts to do updates, or start a transaction (*) will fail with an error indicating the database is locked. This applies even if the two processes are updating different tables. Provided you code handles the errors (by retrying the update until it succeeds), it should work fine. However, if there are lots of processes doing large updates to the same database file, they may be waiting for each other a lot. Contrast this with a full database server (like SQL server, MySql, etc.), which has much finer grained locking, and can let two processes update different tables, or even different rows on the same table, at the same time. (*) Well, depending on the type of the transaction, it may not be locked when you BEGIN the transaction, it may wait until the first attempt to update the database. -- Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming http://www.trumphurst.com/
