Re: Scope of transaction processing wrapper

Yes, that all sounds right.

Just pass the Database variable, and it will all rollback.

This article illustrates transactions:
http://allenbrowne.com/ser-37.html
It all happens in one procedure, so it does not illustrate passing the db,
but the technique is identical, and it does explain a couple of traps.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"rdemyan via AccessMonster.com" <u6836@uwe> wrote in message
news:5d32b3ce99067@xxxxxx
Allen:

Thank you for the response. I'm using different DAO workspace, database
and
recordset variables in the procedures that update Tables B and C. I'm not
using db.Execute type statements, but instead rsXXX.AddNew or rsXXX.Edit
and
rsXXX.Update.

Does this mean that I should pass the DAO variables that update TableA
into
the procedures that update TablesB and C. Do I just pass in the ws and db
variables and then create a new recordset based on the SQL statement that
is
appropriate for each procedure to accomplish that procedure's job?

If so, I assume that these DAO variables should still be closed in the
original module that created them (i.e. where TableA is updated).

Thanks.

Allen Browne wrote:
The answer to your question depends on how you write the changes to the
other tables.

If you write the changes with something like:
db.Execute ...
where db is the database in the ws workspace, then they will rollback.

But they will not roll back if you make the changes with (say) RunSQL, or
through another Workspace variable, since these are outside of the scope
of
your transaction.

I have some unbound forms that I want to use transaction wrappers on when
updating the table. My question is on the scope of what transaction
[quoted text clipped - 35 lines]
handler. Will the Rollback statement roll back the changes to all three
tables (A, B and C) or will it only roll back Table A??

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/databases-ms-access/200603/1


.