Hello mcnews,
access is incompatible with using transactions. It's using client-side
cursors, and it's supposed that the (pseudo-)transaction is commited when
the user navigates to another record. Since begintrans and committrans are
native methods of Access, it is able to recognise them and ignore
begintrans.
You can experiment with using currentproject.connection.execute "begin
transaction" and such. This will work, however the transaction resulting
from it will be wrapped around the normal Access work; so, for example, when
the user modifies a record and goes to another one, Access will indicate
that the record is commited, while in fact it will not since there will be
another layer of transaction around it, and Access will be unaware of it.
The results can be unpredictable.
New programming environments (Visual Studio .Net, specifically) use
client-based cursors, because Microsoft thinks that any programming not for
a web page must be quite an exception, and soon will be forgotten. Web-based
programming effectively looks at the database as big excel table in terms of
locks and transactionas, so using them is now kinda not cool.
Vadim Rapp
You wrote in conference microsoft.public.access.adp.sqlserver on 29 Aug
2006 06:57:48 -0700:
m> mcnews wrote:
m>> i get an error that says there says no active transactions when i
m>> execute CurrentProject.Connection.CommitTrans.
m>> i am executing CurrentProject.Connection.BeginTrans before.
m>>
m>> why?
m>>
m>> tia,
m> this works:
m> With CurrentProject.Connection
m> .CommitTrans.
m> do stuff
m> .CommitTrans
m> End With
m> why?
m> i can only guess that access can somehow keep up with the transaction
m> event this way.
Vadim
