>I'd try first to avoid any record locking, resolving updating conflict in other way.
>
>How can you avoid record locking? If you don't do it yourself, VFP will do it as soon as you try to update the record.

Automatic locking should not be a big issue if you keep transaction shorts. Automatic retries should do it.

>
>>If the locking error occurs in the middle of a transaction, I think you should roll everything back, inform the user, and let them press the "Save"button again to retry the operation.
>
>That's what I do in most cases when there's a problem. But sometimes there's a minor issue that is holding up really complex operations that take a long time. If it's something they can fix, it would be nice to give them the chance to try that bit again rather than having to completely start over.

Leaving the user the chance to retry "part" of a transaction would imply that they can choose not to, thus producing a rollback after having the transaction on hold too much time. A quick user can decide what to do in -say- two seconds. This is an eternity in DB transaction time.

>
>>Why? Because transactions should always be as short as possible. If you left the the transaction in the middle, waiting for the user to retry or abort (remeber users tend to talk on the phone, go to the bathroom, etc <s>), then you can keep a transaction open too much time.
>
>
>That's a good point. Keeping the transaction open is just going to make the locking issues worse. :)

Exactly. This is the point.

>Is there any special circumstance in your case?
>
>Well, they've got some network issues that I suspect are at to root of these contention issues but, other than that, not really.
>
>My question isn't really about record locking. That's just an example. What I'm wondering if there is some way of handling communication with the user without losing your place in the BO code and without adding UI to the BO code.

Of course you shouldn't. You have now your BO into the same exe. The day you put it on a COM+ Server, you'll not be there to click any button. 8-)

Communication between BO and UI should be done in terms of messages. The best approach from a scalability standpoint is to keep even this communication at a minimum.

Feel free to keep discussing this if you have further questions. It's an interesting topic, and it is indeed fundamental.

Regards,