Wiki Home

Transaction Rollbackand Free Table


Namespace: DotNet
I'm puzzled by the inconsistent behavior of a free table in a transaction. (VFP 7) I had assumed it could not be rolled back at all. Apparently, it can be rolled back when part of a transaction with other cursors that fail a Tableupdate, but not if it is the only cursor that fails.

I have a simple test form, private data session, optimistic buffering.
It has three cursors in its environment, all set to optimnistic table buffering.
lvVendors is a view based on a free table.
Customer is a free table.
lvBrokers is a view based on a table in a database. The two views are kept in a separate database.

The form has 3 text boxes, one for each cursor.

Case 1
I open 2 instances of the form and make changes to each cursor on both forms.
I save the changes with a transaction in the first form.
I try to save the changes with a transaction in the second form. It fails, and tablerevert for each cursor brings the second form back to its orginal state.

Case 2
I open 2 instances of the form and make changes only to the customer cursor, (the free table) on both forms.
I save the changes with a transaction in the first form.
I try to save the changes with a transaction in the second form. It fails, but tablerevert keeps the changes made in the free table up to the point of conflict with the changes in form 1.

The datasave and datarevert structures are the same in both cases (based on kilofox)
The save format is
TABLEUPDATE( 1, .F., lcToDo)

The revert format is
TABLEREVERT( .T., lcToDo )

Watching the process in the debugger, both cases do hit the Rollback statement in datasave.
From what little I know of VFP so far, Case 2 is expected, Case 1 is not. Which is why I'm just playing with test forms so far.
Am I missing anything obvious?
Thanks!

---
free table in a transaction. (VFP 7)?
I thought transactions don't work with free tables before VFP 9 (new function maketransactable)
---
Hence the question
( Topic last updated: 2005.01.27 05:51:23 PM )