>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

The tables must be in a DBC to participate in a transaction.