From: "Ann W. Harrison" <aharrison@...>
Sent: Thursday, July 26, 2001 12:46 PM

> >Changing data on a form doesn't 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?
>
> Right. In other systems, I've seen this problem handled like this:
>
> Start transaction
> Read data
> Commit
> User looks at data
> User changes data
> System saves old version of data
> User posts changes
> Start transaction
> Compare old version with current database version of data
> If equal
> Perform update
> Else
> Notify user of changes
> Commit
>

Ann,

Thanks for the response. Here is the interesting part so it's all I am
responding to. What you outline here is, IMO, the way the client datasets
work (such as in Delphi 6). Unfortunately, I can't use client datasets so I
am either forced to continue my current practice, or develop a system of
storing complex relational data from several tables into an object(s) in
order to avoid holding open a transaction. I guess that's my biggest
complaint(?) about this type of execution. It is not easy to develop
duplicate structures for master/detail tables in objects when there are
multiple detail records or even multiple detail tables. I do this in some
situations by dynamically building edit components and filling in their
data. However, in most cases, I still need to update or access the detail
records to perform actions if something changes in the created controls.

However, my main question still remains, as long as I commit changes (even
using commitretaining) whenever I update data, I should avoid [most]
situations where a conflict could occur. Would you agree with that? I
realize that resources are being used but that's not really a concern most
of the time.

Woody