Hey Eric. Now I follow you better.

I usually start the trans before #1 (in your example). That you will roll back to an empty record, but in that case I just fill in again based on the prior entries. My favorite method for doing this (because it's so quick) is to call GetString() before the attempt to save; then, on a failure, throw this delimited string into an array; then, scan the array and fill in each field of the RS.

Just remember to delimit the fields using a string that you would not find in valid data -- I frequently use "%_*_%" ....

There may be other approaches, but this is what I have done in the past.





>> I didn't realize that you were working with a new record. So is this the
>> sequence?
>
>> 1 -- transaction started
>> 2 -- new record added to recordset
>> 3 -- user modifies record
>> 4 -- record is saved
>> 5 -- user continues to modify
>> 6 -- user cancels So, we want to roll back to (3).
>> 7 -- transaction rolled back.
>
>> Am I following you? If so, why have step (4)?
>
>Not quite, but close. More like:
>
>1 -- add new record(s) to recordset(s)
>2 -- display recordset to user in UI, user modifies records, hits save
>3 -- transaction started
>4 -- save parent record
>5 -- save child records / child record recieves error during save
>6 -- transaction rolled back (to 3)
>7 -- user corrects error, hits save again
>8 -- save fails b/c parent record cannot commit (thinks it is updating instead of inserting)
>
>In writing, this, I begin to wonder if the problem is not a matter that the transaction should start before 1 instead of after 2...
>
>Thanks again.
>
> . . . . . . . -- Eric