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



Reply via email to