Peter,

Thanks. I did exactly what you suggested. I'm not in production yet but I guess it will be ok on the day. :)

Marc



>Marc,
>
>Some time ago I had problems using pessimistic locking and error handling so I developed some class code which locks and unlocks records storing the username and station with the table record itself rather than in a seperate 'locked records' file. The pseudo code went something like:-
>
>1. Attempt a lock
>
>2. If successful write username, station, timestamp etc to table and issue tableupdate (so others can see who has record). Otherwise try again (n times or whatever). Store a copy of the current record so that you can restore it if a revert action is taken.
>
>3. Edit record
>
>4. When leaving edit prompt to save changes (if not already saved).
>
>5. On save action blank user data, unlock and issue tableupdate.
>
>6. On Cancel/Revert action recall previous data and blank user data, unlock and issue tableupdate.
>
>I did have some problems where abnormal exits in the middle of an edit could cause user data still to be stored on the table but to be honest it didn't really matter so long as the physical lock was released and other users could still lock the record.
>
>In my first attempt I got this wrong and would only allow edits if the lock status on the file was clear (ie the table said it was clear). You can imagine what happened when an abnormal exit meant that user Joe was accused of having the record locked when he didn't<bg>.
>
>If at first you don't succeed... (so long as it makes sense).