Thanks Srdjan. I am hoping for quick solution where I could perhaps wrap the existing update routine. This routine already operates on free tables, not a database.

>>Hi All
>>
>>Looking for confirmation of a best practice solution to the following scenario:
>>
>>I need to write a routine which will update many seperate DBF tables which are not part of a database. I would like to be able to protect this routine from damaging the tables & indexes if the routine does not complete correctly. So I would like to run the update routine but hold back all changes until the end at which point I would commit all changes.
>>
>>The specific problem I wish to protect against is a crash of the update routine somewhere during the update process. What is the recommended solution using VFP9/SP1.
>
>Hi Jos,
>
>From my experience with dbc contained tables and transactions
>I wld say that; in case of amount of changes/records involved in process being low to medium, wrapping it in transaction will work like a charm.
>
>However in case of substantial data processings, say some proc that updates some hundred thousand records having it wrapped in transaction might end up in a somewhat slow operation especially if you do buffering.
>Proc wld perform at it's paste but then saving buffered data within
>transaction band might lead to a pause/lock, which can last quiet a while.
>
>What I ended up doing in this cases, would be to dump content of those database tables into free tables on alterntive location (as sort of run time backup) prior each big process and then perform whole thing without any
>buffering or transactions involved. If it breaks it is relatively easy
>to revert state, whereas if 'fat transaction' cycle is broken before
>commiting I don't rally know wat happens.
>Never wanted to test it on MY sensitive data :))
>
>Funny thing about VFP and transactions, is that they never implemented
>transactions across multiple database tables but did it for free tables.
>In case you are using meny databases interchangeably, it might make
>sence to 'disband' tables from their databases containers and keep them as groups of free tables in separate folders instead.
>
>
>Ok they will fix that VFP10 I am sure <vbg>