First, sad about the football, but someone has to win.
My point that since Sqlite is embedded its only locking method is the
fcntl type file lock. Any other level of locking has to be supplied by
your application. It cannot perform row and table locks like a DB server.
The extreme simplicity in use of Sqlite is because it uses one file and
no server. It is not possible to emulate Oracle with one file and no
server.
[EMAIL PROTECTED] wrote:
-------- Original-Nachricht --------
Datum: Tue, 04 Jul 2006 19:13:56 -0500
Von: John Stanton <[EMAIL PROTECTED]>
An: sqlite-users@sqlite.org
Betreff: Re: [sqlite] Multiple Users
Hi John
I think, I understand what you will to say....
Sqlite is a single file shared between users just like a word processing
file shared between multiple users. It is not a DBMS server and just
uses the regular fcntl type file locks.
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?
Greeting from Germany
Anne