Hello On Tue, 19 Sep 2006 11:24:02 -0700 (PDT), you wrote:
>Maybe I didn't make the question clear. I'm not talking about locking and >multiple writers. I'm talking about optimistic concurrency control in a >disconnected environment. >:::: >IF anyone has changed the data since you last read it, the UPDATE affects no >rows and you know your update failed due to optimistic concurrency failure. I solved this problem by doing a logical Recordlocking. I connect to a SQL-Server DB always in optimistic Mode... and I open my SQLite-DB as if it was also (and any other DB too). The solution is a logical Recordlocking.That is what I do, before I try to alter a record. I check, if this attempt to write is permitted, to avoid that one User overwrite the changes from another User. Therefore I store (after I fetched the wanted Record) a Timestamp to a specific Table in a external specific DB (a specially Key-Collection). The TimeStamp contains: - the Users ID (Users Domain-ID) - the Workstations-ID (Network-Computername) - the Operating-Systems Process-ID - a initial Timestamp with Date and exhausted Seconds this Day - a Heartbeat-Timestamp (Always after 10 minutes every process updates his own locks) - a Class or Data-ID and - the Records ID (such as a Personnel number, not the RecID). It's needed, to lock also Records in several Childtables with same Personnel number, or so. If this full Timestamp successful written to the Recordlocking-Table, I perform a search to another Record with same tokens. If I found anyone and the founded initial Timestamp is earlier than my, only read is allowed to me. If my own Timestamp is the earliest, I can write and any other user only can read. If this "Edit-Class" is closed, or Programm is ended, the Lock becomes removed. If moved to another Record, the Timestamps and the Records-ID will be updated. If change to another class, the Class-ID will be updated in addition.. Sometimes I search dead or lost Locks and remove them. Dead or Lost Locks are Locks, which Heartbeat is older than 2 hours. In this way I lock also whole Tables or the full DB. That works really successful in a Network-Environment with up to 1500 concurrent users. The real advantage is in that way, that permitted Jobs (started by a Admin) can get and hold full rights. Best Regards Thomas www.thlu.de ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
