
Odd Behavior With CommitTrans
John,
Thanks for your reply. I've posted this question to several groups in search
of an answer, but only included a snipet for
brevity's sake. Every respondant has asked if I declared the variables. So I
guess brevity isn't such a good thing!
I swear that all of the variables shown are scoped properly! We actually
have quite a few developers here working on the problem. No luck
so far. I found someone who has seen this.
Subject: Access97 committrans behavior
Date: 1998/03/18
Newsgroups: borland.public.delphi.database.desktop[More Headers]
I'm working with an Access97 database using DAO3.5 through an OLE automation
connection rather than through the BDE.I'm finding that the statement
myWorkSpace.CommitTrans(dbForceOSFlush);
invalidates all my dataset objects, which must then be reopened before
proceeding. The objects aren't set to nil--but the next call returns an Ole
'object invalid or no longer set' error. Is this normal? Anyone else
seeingthis?
Also, the Microsoft documentation says that the call should be
CommitTrans (dbFlushOSCacheWrites)
but there's no such constant in the type library,
nly{ CommitTransOptionsEnum }
dbForceOSFlush = 1;ThanksBobD
I contacted him and he also has found no resolution to the problem. I've
done some further testing and this bug is very easily reproduced. Not to
mention very frustrating. BTW we are running NT 4.0, I haven't tried to
replicate the problem on Win95.
Yours very befudled,
Doug