Hi Al,

I am using VMP but unless there is some code that I have not yet found, it does not handle problems when using optimistic file locking. Well, it does allow you to configure a dialog to inform the user that it was not possible to save the changes. Because of that, years ago I incorporated a type of pessimistic file locking. VMP has code that fires on the first keystroke into a field that changes a field. From that central code, I have augmented their code to attempt a file lock. If that fails, then the user is alerted, the view is reverted and the screen flips to being all read-only controls. What I did not do was to apply this to all child tables of the screen. That is, when User #1 gets a lock on the parent record, I do not lock all of the child tables that user #1 might work on. Then when user #2 tries to get a lock on the parent, they cannot and are prevented from continuing with the edit.

That has always worked - until now when a different screen altogether only changes some of the child records - I guess I will need to augment the code in the second screen to also get a lock as soon as someone starts editing a row...will have to think about this a bit as the 2nd user is working with child rows from a bunch of different screens.

Thanks...got me thinking


>If you're using a framework such as VMP, does it not handle these details for you if you configure it appropriately?
>
>Other than that - have you given any thought to using pessimistic rather than optimistic buffering? I've never used it myself but I understand it's pretty much required in high-contention environments such as airplane and concert/venue ticketing. As I understand it a lot of the issues you're describing could be avoided.
>
>You'd need to take measures to avoid "lunch lock" but maybe you could use it minimally in critical sections.
>