> > Just as a suggestion: In most of my applications, we have a security layer > which is implemented through server-side functions. These functions keep a > table updated which contains: > > lock_table > record_id > lock_user > time_locked That's an excellent and even portable idea. > > This allows us to avoid nasty "your update cannot be processed"-type error > messages by showing the user up front which records are locked, as well as > allowing the admin to decide when locks should "time out". > > I tend to find in general that database locking mechanisms are a very poor > locking strategy for a good UI. > True. But you circumvented it elegantly.
Regards, Christoph ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
