>>>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.
>>
>>I understood your post. Just wanted to warn you that in case you hv huge amount of data you might end up with the simillar pause/lock I described.
>>Once you wrap free tables into transaction band by applying
>>MakeTransactable() , perhaps the same thing might happen.
>>(Aldough I never tried it.)
>>
>>This might be helpfull perhaps
>>http://fox.wikis.com/wc.dll?Wiki~TransactionsAndBuffering~VFP
>>
>>There are code samples there that you might find usefull.
>>
>>HTH
>
>Thanks Srdjan.
>
>I have got a solution working using MAKETRANSACTABLE() and BEGIN - END TRANSACTION. I can crash the routine half way and no affect on the underlying databases. As a test I run the update routine in a VMWare virtual machine and just switch off the virtual machine without any adverse affect on the tables or indexes. Cool.

Sure is cool / good news for me :)

Never used transactions on free tables because when I was building my
datahandling stuff (back in vfp6) they were not possible (that is why I don't use free tables at all) but it is good to know that this would work just as good as with database tables if I tried it now with VFP9.

BTW Did you try it with higher data volume (applying changes on few100k )
Is there noticable delay/pause when saving with transaction band ? Or this was maybe happening to me because I was trying to save buffered tables (buff.5) with transaction band arround.

As I said before, it would hv been great If there was possibility to apply transactions on both free tables AND database tables, and why not across tables contained in multiple VFP databases.
Am I am being humble here or what;
Is that to much to ask from discontinued product ??? <vbg>