>>An example of when you might want to do pessimistic record buffering is if, say, two salespeople are talking to customers about the same stock item. If the first one to the stock is "doing a deal" < s > with a customer, the second should be told (IMO) that it's not necessarily available...It hasn't actually been sold out of inventory yet, but he can't really sell it.
>
>This is almost exactly what I'm wanting to do. I've got these forms that are being processed and I want to make sure that if User A is processing a form, User B can't also process it.
>
>Since it appears that all I have in the client/server world is op buffering, any idea how I could accomplish this before User B starts up (and wastes their time).
>
>Thanks for any help. Y'all will please have to forgive these questions, but i'm completely new at this and want to get it done right (although I'm not sure how I'm going to do that by Thursday... but I'll never give up until we walk into the meeting :) ). Thanks again.

PMJI,
But this might be what I call process locking... you only wan't to allow one user at a time to carry out a certain task. This can be done quite simply with an extra field in the user table called "process". A form, or any process which can only be processed by one user at a time can be given a unique name/identifier programmatically and stored in that users "process" field. Before this is allowed you check the user file to make sure that no other user is undertaking that same process. The advantage is that you can advise the user "You can't do this just now because John Brown is doing it" - something that's much more difficult with record locks. Just clear the field when finished.
If you don't have a user table create a ddummy one and assign psuedo userids at login to your system.

HT Helps and makes sense :-)