Jim,

Just took a look at it. Seems it might work. I'll probably order it to see. Nice having a deep corporation purse -- you can do stuff like just buying tools to look at them.

Thanks very much for the steer...

regards,

jim


>Hi Jim,
>
>reading your reply (could be a fair bit of work) the thought occurred that the FoxAudit product **might** be useful to you here.
>
>I have **NO** experience with the product. Just a memory of good reviews and a sense of potential usefulness in your application.
>
>Good luck,
>
>Jim N
>
>>Craig, Josh,
>>
>>Thank you for the insight. Because the database we are trying to rollback is likely to be large, Josh's point is of concern to me -- particularly since our users are not likely to have an up-to-date backup. I suspect, therefor, we had best write our own rollback method.
>>
>>Again, thank you,
>>
>>regards,
>>
>>Jim
>>
>>>Jim,
>>>
>>>In addition to Craig's point, you should also know that VFP does not provide true transaction processing. That is, if your computer crashes while committing a transaction it is possible for part of the transaction to be committed. This will only happen if your computer or application crashes while VFP is actually writing the transaction to disk when you END TRANSACTION, but the larger the transaction the higher the likelyhood of this happening. If you need to absolutely guarantee that the transaction is completely committed or completely rolled back you'll need to use a server database like SQL Server or Oracle.
>>>
>>>>Howdy (Texas talk for "Hi All")
>>>>
>>>>I have a situation where I would like to surround some multi-table transactions with BEGIN TRANSACTION/END TRANSACTION and rollback to the previous table states if the entire series of multiple transactions is not successful.
>>>>
>>>>Since this will require the opening and closing of many, many tables in at two differnt sites, and the creation and destruction of multiple cursor, I am wondering if it is even practical.
>>>>
>>>>Any thoughts or advice would be appreciated.
>>>>
>>>>TIA