>Since a few years, many applications does not include a modify command button anymore as the update process will be fired automatically when the user will start changing a field in the form. In some cases, there won't be any update as the user only want to view the data.
>
>In many applications, we now uses optimistic buffering for the data entry form. This means, a user can view the form for about 2 minutes and decide to start making changes. Because we are still in buffering, we do not have any guarantee that the data being changes is what is on the disk as another user might have updated the data during that 2 minutes. We will then resolve the conflicts at same time by given the user the appropriate information and decide what to do.
>
>We also have applications where the environment need to be pessimistic. We may then have a situation where many users are viewing the same record. Now, one user starts changing something. The lock is now applied. However, it may happen that someone else updated that record while the user was viewing. What will happen, is as soon as the user changes field, the field will be refresh with the actual value from the table. We may also force a ThisForm.Refresh() to make sure the entire fields are refreshed at once.
>
>The last situation is ok when working with local tables as the form is mapped to the local data. Now, what about working in ODBC? Because, we can't have a direct access to the data, we can only get a set of data when doing a call to the backend. Does this mean the best approach is, as soon as we detect a user starting to change something, we will fire another call to the backend to get the latest data in case someone changed that record while we were viewing it?

Logically, it's enough to use initial buffer, because you still have opportunity to give a user opportutnity to resolve field value conflicts when saving. BTW, I am curious, how often your users requests for elaborated mechanism involving GETFLDSTATE,etc.