I've tried
CurrentProject.Connection.BeginTrans
' This acts as if you didn't begin a transaction.
' Changes are posted real time then gets an error on Commit that you are not in a transaction
Private conn As ADODB.Connection
Set conn = CurrentProject.Connection
conn.BeginTrans
' This fails silently in the sense that nothing posts to the database when it gets committed
Set conn = New ADODB.connection
conn.Open GetConnectionString
conn.BeginTrans
' This fails on the first SQL statement with
' "Object variable or with block variable not set"
' But it clearly is set because it works if I don't start a transaction
' You would think that starting a transaction explicitly would work.
Private conn As ADODB.Connection
Set conn = CurrentProject.Connection
conn.Execute "Begin Transaction", , adCmdText Or adExecuteNoRecords
' This also fails silently in the sense that nothing posts to the database when it gets committed.
Commit looks just as you would expect. Whichever of these is appropriate:
CurrentProject.Connection.CommitTrans
conn.CommitTrans
conn.Execute "Commit Transaction", , adCmdText Or adExecuteNoRecords
Nothing works.
I can easily get it to work on DAO.
DAO.Workspace.BeginTrans
works just as you would expect, except that only DAO statements are committed. Anything posted through ADO is lost, disappearing as if they didn't happen.
But I don't want to switch hundreds of SQL routines to use DAO if I can avoid it.
Note that I'm not trying to create a new connection to the back end. These are all linked tables, with Access compatible SQL statements.
The solution I posted here, doesn't appear to be working after all.
What is the recommended approach to transactions in ADO on local tables?