>>>>I have a form I need to revamp that uses multiple views based from a single table. There is a grid populated by one view. Some processing will occur that will involve scanning and switching between views and moving/copying records depending on flags that are set for the records displayed in the grid. There are no relationships between the views. I plan on using Table Buffering and am having a hard time getting my mind around how I need to handle the adds/deletes/updates for the different views. Is the best way to make all changes to all views then do the updates on the individual view? Is there a better way or more accepted way? This is new to me as I normally have only one record to update at a time and I have a oApp class to handle it as needed. Thanks!
>>>>
>>>>Regards, Renoir
>>>
>>>Renoir,
>>>Multiple views or multiple instances of same table or multiple users of same table. They all could be seen as same IMHO.
>>>PS: If only from a single table wouldn't it be easier to work directly with the table itself.
>>>Cetin
>>
>>Cetin,
>>
>>Maybe so, but the logic is that there is a field in the table and it's value determines the contents of each view. When working in the MyMain view, based on a flag I might need to take a record from the MySecondary view, compare it to a record in MyTertiary view and then move/copy the record back into the Main view. It seemed that the easiest way was to have separate views.
>>
>>Renoir
>
>Would transactions be a good solution for this issue?
>
>Renoir


Either don't break the link between server and client -- by opening the table multiple times as Cetin suggests.

Or, if you do, copy the data down once to the workstation, filter to the various interfaces, manipulate the data on the workstation only. For example, if you store the filtered data to list boxes, and move individual items about, you'll need to manage that at the form level. Only when the process is completed store it to the server. It gets overly complex to manage transactions, views etc. when you only want to commit changes at the end of the session, just to keep your local data in sync.

A lingering question I've had is your data model. I can imagine some scenarios in which you'd need to do what you're describing. But, when my data model can be better normalized, doing so often offers a simpler mechanism. So, just want to raise the question.


Jay