Depending on your application, locking a record while it's being read has problems. Users will inevitably open a record then go to lunch, maybe leave for the day. Perhaps the app crashes or a lightning strike shuts everything down as soon as they open the record. If you take this approach (or any approach involving multiuser locking) you will need a maintenance utility to unlock all orphaned locks.
The vast majority of the time this will not be a problem, as another user would access the same record by happy (or rather unhappy) chance. But as developers, we have learned not to leave anything to chance. Chance is our gremlins hiding in the closet, waiting for us to feed them after dark. What I learned from an old multiuser accounting program was to maintain some kind of counter column, incrementing it (or resetting it when it gets to the highest value) whenever an update occurs. Before the write, but after you lock the table for updates, check the value against what it was when you read it. If it's not the same, someone else updated it first, so reset the data. Bob On Sep 27, 2012, at 5:13 PM, Dr. Hawkins wrote: > I've been pondering this, as I'll be going multi-user shortly. > > My thinking so far is to lock the record in the SQL database upon > load. If someone else tries to access, they would be informed of > read-only status (and offered a chance to break the lock if it's old > enough.) _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
