ODBC + Access 2.0 + VC1.52
Glenn T. Jayaputera -- gtj@nunkeen.apana.org.au
Monday, July 29, 1996
Environment: VC1.52 + ODBC + Win95/Win311
Wondering if somebody can shed me some light. I am trying to manipulate Access 2.0 database
using ODBC (v2.10 I believe) from my 16-bit App ( vc 1.52 ). I am trying to use transaction
mechanism but the call to CanTransact() returns FALSE;
My understanding, from reading the manual I would be able to use this transaction mode over
Access v2.0 database using ODBC driver. Am I missing something here ?
ta
glenn tesla
Kit Kauffmann -- kitk@mudshark.sunquest.com
Thursday, August 01, 1996
[Mini-digest: 5 responses]
>Environment: VC1.52 + ODBC + Win95/Win311
>
>Wondering if somebody can shed me some light. I am trying to manipulate
Access 2.0 database
>using ODBC (v2.10 I believe) from my 16-bit App ( vc 1.52 ). I am trying
to use transaction
>mechanism but the call to CanTransact() returns FALSE;
>
>My understanding, from reading the manual I would be able to use this
transaction mode over
>Access v2.0 database using ODBC driver. Am I missing something here ?
>
>ta
>glenn tesla
(Not using Access, so any suggestions may be suspect :)
I'm assuming your CanTransact returning FALSE is a call to SQLGetInfo(
SQL_TXN_CAPABLE ) which returns FALSE - this implies that your ODBC
connection will always be in auto-commit mode, according to the docs.
We use Sybase, and the drivers for it allow us to turn off auto-commit, if
desired, and use SQLTransact, in either mode, but we have found that using
SQLTransact in either mode can be problematic, especially when using stored
procedures and/or triggers which contain transactionality.
However, what works well for us, and may be a solution for you, is to send
the "BEGIN TRAN", and "COMMIT" or "ROLLBACK" SQL verbs to the SQL server
yourself, effectively using the server to control the transaction, rather
than ODBC (and we always use auto-commit mode).
Not only does this seem to be more reliable than the SQLTransact call, but
it also keeps the server in control of the transactions, presumably allowing
the use of external transaction control mechanisms (like 2-phase commit)
necessary in a distributed DB environment (note, though, that is an untested
presumption on my part).
HTH!
Press any key... no, no, no, NOT THAT ONE!
-----From: spatters@smog.ess.harris.com
Glenn,
I just had the same problem.. Check out the KB atricle "How to Perform
Transactions with the MFC Classes" Q128208. It states:
"One major requirement of the MFC transaction model is that the driver
support cursor preservation across transaction commits and rollbacks. This
requirement prohibits transaction support when using most ODBC drivers.
None of the drivers shipped by Microsoft to date meet this requirement."
But it gives an example of how to overcome this limitation.
Stuart Patterson
-----From: chris.downs@slug.org (Chris Downs)
I've been using that setup except with SQL Server 4.21a. I also get
the same thing; CanTransact() returns FALSE, but transactions work
just fine anyway.
I suggest you test it and see if transactions work regardless of
what CanTransact() says.
-----From: Jonas Andurйn
I had the same problem some time ago and I found the answer on the MSDN C=
D. There was an article from the Jet=20
Database programmers guide that told me how to do. Basically there is onl=
y three things you have to do :
1) Subclass CDatabase
2) set the variable m_bTransactions to TRUE
3) ALLWAYS make a requery directly after your commit/rollback.
I don=B4t know if I can post the whole article but if you have the MSDN C=
D=B4s search for ODBC and Transactions.=20
The article is called "Using Microsoft Foundation Classes" and it=A8s (as=
I mentioned) in the Jet Database=20
Programmers guide.
// Jonas A
-----From: Dan Kirby
There is a knowledgebase article about how to use transactions with the
Access driver. I believe it is called something like "Improving
performance with the Access ODBC driver". Just search the knowledgebase
for BeginTrans and you should find it.
The basic idea is that you will have to force them_bTransactions to TRUE
for the recordset and you will have to remember that your cursor will not
be preserved after rollbacks or commits. If you plan on requerying on the
same recordset after doing a rollback or commit, you will need to call
SQLFreeStmt to close the cursor and then requery. The article talks about
this.
--dan
| Вернуться в корень Архива
|