While looking through the Web Application and Construction Kit, they had a section on Row locking while trying to update a value. They assign to the locked column a 1 to lock it. Only one problem, isn't it theoretically possible that some one else could be doing a "Locking" update on the same row.
Ex User1: Search => Finds row 10 unlocked User2: Search => Finds row 10 unlocked User1: Since Row 10 unlocked lock row 10 By updated the locked column to 1 on the Locked row User2: Since Row 10 unlocked lock row 10 By updated the locked column to 1 on the Locked row When we move to the more robust and multithreaded Witango 5 the above locking scheme may not work. Wouldn't it be better to use the <@USEREFERENCE> to truly lock the Row? This way when the final update is done it is compared with the <@USERREFERENCE> since it is unique? Any Ideas? Jose -- Webologies 150 Robinette Drive Waynesville, NC 28786 828.627.1994 http://www.webologies.com ---------------------------------------------------------------------------- "You can't make an omelet without breaking eggs" Boris Badenov ---------------------------------------------------------------------------- ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
