There is another option as well. You could code in your program that if there's no activity within xx minutes, then you rollback the transaction. This way, your users will quickly learn not to leave half finished work at their desktop.

HTH,
Set

Larry wrote:
The window I'm thinking about offering will have child windows, where they can alter records that have several unique varchar columns. They might alter a varchar column that will cause a colision. Not a problem, the app will warn them of the conflict and ask if they wish to proceed. They can repeat this on other rows and do a lot of updates inserts and deletes. And when they are finished they might decide they don't like the results of what they've done and hit "Cancel".

If I start and commit transactions each time the user updates the database, I wont be able to roll them back if the user changes their mind, and hits "Cancel" when quitting the parent window of this activity.

> > I wouldn't be surprised if people go to lunch, or even go home for the weekend, while the window, and transaction, are open. They could even turn off their PC or the server could go down for maintenance and never properly quit the window and commit or roll back the transaction.

I value your opinion. If I do offer this window I might just inform the user that the changes they make are not reversible once they hit "OK" on a child of the parent window. This will allow me to use my normal pattern of a transaction to load the contents of a window, and a short lived transaction to respond to the "OK" button.

If they make too big a mess? I hope they follow my admonition about using the "Backup The Database" button.