I'm not sure I understand exactly what you are doing. But what I can tell you is that the best way to build a system in which the data source might change (VFP tables to Oracle), is thru the use of SQL Views.

For example, in a data entry screen, a SQL View would be based on the main table. It would consist of the record currently being edited, or a blank record in case of an add. Once the user selects save a TABLEUPDATE() is performed to update the main table with the new data.

If you look up SQL View you will notice it is basically the same weather it points to local data or Oracle data. Just a few different parameters.

I think that what Jim Booth was trying to point out is that in a scenario such as this, buffering is a feature that is part of this way of doing things. There really is no decision to use or not use buffering. It is the way to get information into a SQL View table.

PF

>I have created a model for an application in which the database is updated via SQL UPDATE and INSERT statements. I manage the transactions and the effect of success/failure of the transactions by monitoring the _TALLY variable. I didn't feel any need to utilize buffering.
>
>Is there a deficiency(ies) to this approach? Are there advantages to this approach?
>
>FWIW, I am expecting to migrate the database to Oracle where VFP is simply the front end. My impression is that my model would be closer to this possible client/server model (which I would perceive as a positive aspect).
>
>Thoughts?
>
>Thanks.