I would not like the method of saving data you mentioned being in my app. However if can you encapsulate the write into a function who cares. In other words if you just do a SAVE() as long as data does not get corrupted saves are dependable and fast enough for the business at hand who cares.

I am thinking I have seen somewhere in MS SQL Server a switch that allows for SQL to first write a new record and then delete the original on an update. If my memory serves me right then I would suggest that doing this in other types of db apps is probably ok as well.

What is best practice would probably really be hard to determine. I never use buffering myself. I am converting a VFP 3.0 app to VFP 7.0 SQL Server. The app was originally based upon the original Codebook framework. Buffering is buried deep with in the framework hierarchy and in this context I despise it. But it works

Having said that the same app has some interesting ways to control enablement of certain toolbar choices that really only are watching for data buffers to become dirty.

Try using a third party Active X Control in a form such that the active X control does not bind to data. In other words you have to populate the active X control with its own ADDItem method. When you want to write data you have to interrogate the control to get the data out of the control then specifically write the data to the original table. I don't know that buffering really helps here. There is so much manual marshling of data around it probably would be better to be consistent in being more manual in the save code.

There is one recent example in a big module I am working on that SCATTER/GATHER NAME was the best choice because this let me abstract what I was going to have to move out to SQL. In other words one function could figure out on its own what to write back out to SQL on many tables (80)

The point: First try to learn all of your options on writing data then try to learn where each one works best. See if you can learn from why it was done this way. Change for the better the things the budget will allow.

Final point as data gets more and more GUI'd into different front ends (Fat Client/Web/PDA/Phone ETC) binding of data to controls seems to get used less often so you have to be skilled enough to know how to save data different ways.