[EMAIL PROTECTED] wrote:
but... I want try to ask again... ;-)
SQLite handles the File-Lockings as a physical Locking during the
writings to File and Disk. (Is it so?) I do my own logical Locking
during the Edit of a Record and then reflect to the Busy-State if the
changes will be saved to disk.
The different point of views are intended from a logical Lock during
Edit and a physical Lock during storing the Data to Disk. A logical
Locking can hold it for a long time, several minutes, to a hour ... so
long the user need to hold this Record for Editing. But there is during
editing no affect to DB. This will done very well in my Logical-Locking-
Concept. The physical File-Locking needs only milliseconds, even to write
changes to Disk, if DB Ready and not Busy.
Now then...if the User-Edit endet, the changes will be saved to File
and written to Disk, and that is controlled bei File- Locking through
SQLite, so that multiple Diskwritings to one DB do not end in a
collision.
Is that accurately described?
Anne,
Yes, your description is correct. SQLite does what you are calling the
physical locking, and your application will have to do the logical
locking itself. SQLite will help with the logical locking by providing
physical locking that will prevent two users from updating the database
to acquire the same logical lock. SQLite's physical locking will ensure
that only one application instance can write to the database to either
acquire or release a logical lock. As long as all your applications use
and respect your logical locks, then this scheme should work well.
HTH
Dennis Cote
