> OK, let's see if I got this straight then. I use IBX so anytime a commit is
> done it closes my view of the data (tables, queries, etc.). So, unless I
> switch and use some type of client-side dataset, I can't commit the
> transaction until the user moves to the next (or another) record.

CommitRetaining()

> Changing
> data on a form doesn't necessarily change the data on the server so it's
> really not in an inconsistent state as far as the server is concerned. It's
> only when I actually "post" the data that it becomes a new version of the
> data, right? So, as long as I commit after posting changes, I should be OK.
> I rarely use update/delete queries to update data directly on the server
> except for certain mundane tasks that are quickly executed and committed. I
> always commit after any posting of data changes so the only "long" running
> transactions (generally no more than 10 or 15 minutes) are read states which
> shouldn't affect anything.
>
> I guess my biggest confusion comes in because I use all data-aware controls
> and don't store the data in some form and then use an update query to change
> it. So, I assume that the biggest problem that I face is when user A reads a
> record and user B reads the same record. Then, user A changes the record and
> commits and user B changes the record and commits, right? In this case, user
> B gets a dealock error and rolls back their changes.

Why would B get a deadlock if A has already committed?