Re: LOCKS???

Paul: > On Dec 1, 2016, at 1:11 PM, Paul M Foster <paulf@quillandmouse.com> wrote: > I think you're *far* better off doing your "locking" by record. Yes, I agree. Now that I look back on what I’ve written, I‘ve been mixing locking tables with locking records. I’ve always meant the end result would be locking records — no real reason to lock tables. I only started experimenting with locking table to see if I could get locking to work, which it didn’t in php. My end solution would have been locking records and not tables. > But this whole sequence is why I've never tried to implement any kind of > a scheme like this. The idea of taking a run at a record (after edit), > compare content, presenting a "diff", running at a record again, > possibly taking another "diff", etc. would be maddening. The repetitive > processing of a single record, possibly ad infinitum, would be > "cost-prohibitive", not to mention technically unbelievably complex. > Imagine that for every "Save" screen, you have to do an "Are you sure?" > screen. Not exactly that. What I am currently focusing my efforts on is: Let’s say two (or more) users open the same record at the same time. At the start of their editing — ALL users scripts read the current record timestamp (i.e., the time the record was last modified by the last user). That timestamp becomes pivotal in permitting future saves — let’s call it T. When any of these users attempt to save their data, their script looks again at the record’s timestamp. If the record’s timestamp is the same as the one they started with (i.e., T) , then save is permitted without any interference whatsoever and a new record timestamp is established. The user never knows a "compare and verify" has been preformed. However, if the record’s timestamp is different than their T, then the record they are working on has changed. Their script then compares the current record data with the data provided by the user AND establishes a new record timestamp and a new T. If the data is the same, then no need to save and the user moves on as is they had saved. If the data is not the same, then the user is shown ONLY the data that is different between the record’s current data and the data the user entered and asked “Which data do you want to save?”. After the user makes their choices and attempts to save again, the record’s timestamp is again read and compared to T. If they are the same, then the data is saved and a new record timestamp is established. However, if the timestamp has changed again, then the user goes through another “Which data do you want to save?” procedure. This “compare and verify" procedure repeats until all users have their say. Note: This method does not require every user’s save to go through a multi-confirm save. It only requires the “compare and verify" IF there is a conflict in data as suggested by new and old timestamps. I think this will work — what do you think? Cheers, tedd _______________ tedd sperling tedd@sperling.com