Ann don't cry into your beer, there is always next time! My team also
got knocked out by Italy.
Your approach makes perfect sense to me. Perhaps you can achieve it be
defining a database wrapper which encapsulates the DBMS APIs and
provides a standard interface to your applications. You might need to
add some deadlock detection and synchronization in the Sqlite wrapper.
My CS Professor used to say "There is no problem in Computer Science
which cannot be solved by yet another level of abstraction" (I hope your
English is good enough for that, I cannot put it into German).
[EMAIL PROTECTED] wrote:
-------- Original-Nachricht --------
Datum: Wed, 05 Jul 2006 13:01:12 -0500
Von: John Stanton <[EMAIL PROTECTED]>
An: sqlite-users@sqlite.org
Betreff: Re: [sqlite] Multiple Users
First, sad about the football, but someone has to win.
Its only football... and so hard it is... the italian players
are the better players. But our coach has done a greatly work.
We can be content with this result.
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.
Thats not my intention. I dont want to blow up a Single-File-DB like
SQLite to a Server-Based DBMS like MS SQL-Server.
But I work with various DB, and I like to do handle all at the
same way. It is be much easier, to access and repeat my own
knowledge, if I support a frontend and all frontend looks similarly
at the Database-Connect-Level.
And... why should I don't handle a SQLite-DB as a Backend like a Server-Based
DBMS? Its imho primary the same.
If I allow more than one User to "connect" to a DB, I have to
manage the access of all this users, particularly the concurrent Edit
of one and the same Record. The Problem exist not during the Dialog-
Edit. The Problem occurs after read Data and stay on Screen, at the
End-Editing, then, if changes written to Disk.
Other Users is allowed to fetch this Record too and present it in his
own View - but only as Read-Only. I do it at the same Way like SAP.
All User can fetch "this" record and present it in Dialog-View, but
only the first reader can edit and store his Changes to DB.
Greetings, Anne
