Edit method in DAO changes values?

[TC]

Get back here, if you get a different result. I'm sure I've got it right -
but if not, I'll need to review my own code. I suggest you run the tests
that I described before, when you get time.

Cheers,
TC

 

[david epsom dot com dot au]

"In earlier versions of the Microsoft Jet Database Engine, SQL statements
were automatically embedded in implicit transactions. If part of a statement
executed with dbFailOnError failed, the entire statement would be rolled
back. To improve performance, these implicit transactions were removed
starting with version 3.5. If you are updating older DAO code, be sure to
consider using explicit transactions around Execute statements."

DAO 3.6 .Execute help page.

That page is otherwise based on the DAO 3.5 page, but the DAO 3.5 page (at
least my version!) does not contain that paragraph.

Same stuff on Web: Apparently hidden page in MS library: (note the URL)

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dao360/html/damthexecute.asp

cf Jet 3.0:
"· Implicit transactions are built into the Jet database engine, so you can
take advantage of the improved speed provided by transactions without using
the BeginTrans and CommitTrans methods in your code. To retain full control
over when data is written to disk, you should construct explicit
transactions by using the BeginTrans and CommitTrans methods."

So, do implicit transactions make things faster or slower? If you could
take advantage of 'the improved speed provided by transactions without using
BeginTrans', why did Access 2.0 programmers use BeginTrans/CommitTrans ??

Reading the Jet 3.0 documentation again, it appears the Jet 2.0 DID have
implicit transactions, and they were always synchronous. Jet 3.5 introduced
the /asynchronous/ option for implicit transaction, which allowed the jet
engine to consolidate lock actions. This was claimed to give the performance
advantages of explicit transactions, without requiring explicit
transactions. The Jet 3.0 documentation quoted above was possibly just
misleading stuff written by someone who did not fully understand.

Further: it was already known that Jet 3.5 may do a 'partial commit' if it
runs out of resources while doing a transaction. Is it possible that this
only meant that implicit transactions were no longer supported? (That would
be a forgivable offence).

Further: 'Implicit Transactions' are an ANSI requirement (DML statements are
Atomic). By removing implicit transactions from Jet 3.5, MS moved Jet away
from ANSI standards (ANSI SQL predates ANSI 92 SQL).

Further: No trace of this that I remember in any of the conversion white
papers.

(david)

 

[david epsom dot com dot au]

Ok here it is:

ACC97: Microsoft Jet 3.5 Performance White Paper Available in Download
Center
http://support.microsoft.com/defaul...port/kb/articles/Q162/7/01.asp&NoWebContent=1


"Even with all the work in Jet 3.0 to eliminate transactions in order to
obtain better performance, SQL DML statements were still placed in an
implicit transaction. This negated some of the performance work and
typically resulted in DAO looping code to substantially outperform SQL DML
statements. Jet 3.5 has removed that restriction and SQL DML statements now
are no longer placed in an implicit transaction. This results in a
substantial performance benefit when running SQL DML statements that affect
many rows of data."

and:

"With Jet 3.5, an explicit transaction will automatically partially commit
when more than the default setting of 9500 locks have accumulated. "

(david)

 

[TC]

Ok here it is:

I think you mean: "Yes, you were right all along!"

Cheers,
TC

 

[david epsom dot com dot au]

I think you mean: "Yes, you were right all along!"

Fair call :~)


(david)