I was working on a cascade delete for a form and wanted to wrap it all in a transaction so that if one of the views failed to post via TABLEUPDATE(), I could easily roll back all the deletes up to that point. I had optimistic table buffering on all the views and tables.

In testing, the ROLLBACK rolled back the deletes I did on the local views but then when I looked at the actual "real" tables, the delete flags were still there. These tables are FP26 free tables. I poked around after reading a bit (it was not clear in the docs) and it seemed that maybe the tables concerned have to be a contained VFP table for the rollback to work. I tried this against a contained table and the ROLLBACK took off the delete flag on both the view and the table correctly.

And so it seems that the transaction really only works on contained views and tables. Could someone confirm this please.

Note that I cannot switch to all VFP tables at this point as the customer's main app is a 2.6 app and this new app has to hit against the same data.

Albert