Hi Thom,

I have an example of using sqlexec() natively with a postgres backend server. It does not use buffering. However, you can do a revert by clicking on a revert button that refreshes the from's grid with the current state of the backend server. I have considered using buffering in my foxpro front end program, as it would not produce any overhead in the backend server when a tablerevert was issued, but would rather put the foxpro client back into the state it was in before the transaction began. I could have a button for each way and let the user decide whether to revert with a requery or a tablerevert(). Also, my example app only updates the backend server when a button is clicked initiating the sqlexec update and isert commands.

Anyway, I think you are correct in assuming that the view updates the backend after each row advance. You might try a cursorsetprop command to put the view into optimistic buffering method 5 if this is possible. You might have to put the view in a form to accomplish this. Then the table update would only occur when you selected the button to perform a tableupdate.

My web site is currently in a mess, so you would not be able to download my example app right now. I emailed a version of the app to UT, but have not had a chance to download it from UT to see if everything is working correctly.