AFAIK, a major application I wrote uses explicit record locking in exactly one place - perhaps I could replace that, too.
The basic idea - of not using rlock() - is to use optimistic buffering, and let VFP do the record locking automatically.
In this case, records are only locked briefly, when the user saves changes to the record, with a save button (command TableUpdate()).
If the user decides he doesn't need to save, there is no record locking at all.
>I posted a question earlier that used record locking as an example, which started an interesting discussion with Martín in which he suggested not explicitly locking the record at all. My first reaction was that would be silly since then you don't know if you weren't able to get a lock. But, after thinking about it more, I started to wonder why we should treat this any different than any other error?
>
>I was under the impression that not dealing with record locking yourself was a bad practice, but maybe not? Is it just an old fashioned way of doing things? I'm curious to hear what more people do. Let VFP handle it and treat it as an error if it can't get a lock? Keep trying to lock the record yourself and do something special if you can't? Something else?
>
>Thanks,
>
>Michelle
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)