Problem with Rollback in DAO 3.6

[Colin]

I am having a problem when doing a rollback using DAO 3.6 in VB6 on both
Access 2000 and Access 97 databases. The sequence of instructions are as
follows:

Open a recordset using DAO
using .FindFirst find the first record in the recordset...OK
Begin a transaction
using .FindFirst find the second record in the recordset...OK
rollback
using .FindFirst try to find the second record in the recordset...it is not
found

After the rollback none of the records except the first appears to exist in
the recordset. Requerying the recordset gets all the records back again. The
recordset is a simple (no joins, no ordering) opened with dbOpenDynaset,
dbInconsistent, dbOptimistic using a "SELECT * FFROM ..."). If I use DAO 3.51
(on the Access 97 database) there is no problem. I am using Windows XP and
the version of dao360.dll is 3.60.8618.0 which I believe is the latest
version for XP SP2.

Can anyone confirm this behaviour and does anyone know of a fix for it?

 

[IUnderstandSomething]

I am having a problem when doing a rollback using DAO 3.6 in VB6 on both
Access 2000 and Access 97 databases. The sequence of instructions are as
follows:

Open a recordset using DAO
using .FindFirst find the first record in the recordset...OK
Begin a transaction
using .FindFirst find the second record in the recordset...OK
rollback
using .FindFirst try to find the second record in the recordset...it is not
found

After the rollback none of the records except the first appears to exist in
the recordset. Requerying the recordset gets all the records back again. The
recordset is a simple (no joins, no ordering) opened with dbOpenDynaset,
dbInconsistent, dbOptimistic using a "SELECT * FFROM ..."). If I use DAO 3.51
(on the Access 97 database) there is no problem. I am using Windows XP and
the version of dao360.dll is 3.60.8618.0 which I believe is the latest
version for XP SP2.

Can anyone confirm this behaviour and does anyone know of a fix for it?

You start the transaction before the OpenRecordset and use rollback if
things go wrong in the error handeling. What is it you want to do?

Sincerely

Hans Kristian

 

[Colin]

Hi Hans,

The recordset is opened before the transaction is begun. In the real
application I would be working through the recordset in a loop and would, at
some point, begin the transaction. I would then edit and update the current
record in the recordset. Once I have edited and updated the record I then do
some checks to see if the data we had changed is OK to change (this is
actually quite a complex validation process). If something fails to validate
then I need to report this to the user and to rollback the changes I made to
that record so I either commit the transaction or roll it back. I then move
on to the next record in the recordset and continue round the loop until EOF.
I found that I was exiting the loop early if ANY record failed during
validation as it reached EOF immediately. So I wrote a really stripped down
version of the original and discovered the problem as described in my first
post.