On Wed, Dec 06, 2006 at 11:36:11AM -0600, John Stanton wrote: > I fully understood. It is an age old problem that has puzzled > generations of system designers. My first exposure was over thirty > years ago. The approach we discovered worked was to treat it as a > transaction in the logical sense. The decision then becomes one of > granularity because obviously you cannot keep the whole DB locked to > handle one item if you have multiple users. > > Logic using a committed journal and an application implemented rollback > and commit can effectively implement the transaction in a multiple user > environment.
Another alternative is to run UPDATE ... SET ... WHERE column1 = <value_read_earlier> AND column2 = ... and then check if the update happened -- if it didn't it's because the data read earlier was stale; recover by re-selecting the data, etc... Let the user see what SQL is executed, let them type in their own, and by and large you're there. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
