Bug? in TADOConnection.SetConnectionObject
- From: "Paul Scott" <paul.scott@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 20 Dec 2007 16:36:05 -0000
Hi,
I tentatively suggest that there may be a small problem in AdoDB and report my findings so that I can be shot down by the experts or build up a proper QC report.
A similar situation was described in this newsgroup on Feb 24, 2000 ("Connection sharing between modules") but the AdoDB code doesn't appear to have changed...
Background: I have a connection to the "current" ADO database (actually MS Access)
My program synchronises databases in one of two directions:
1) Listing the differences between "current" and "previous" versions
2) Merging into a "newer" database some private data from the "current" version
Each synchronisation creates two AdoConnections ("This" and "That")
Depending on the synch direction, one of these creates a new connection to an Access Data File (by building a ConnectionString and calling "Open") while the other just piggybacks on the existing (open) connection "aAdoConnection.ConnectionObject := aConnectionObject" and records the fact that it is piggy-backing - because it must not close this connection when it finishes the synchronisation.
When the synchronisation is finished - and this bit all works wonderfully well - I explicity nil the ConnectionObject for the piggy-backed AdoConnection so that neither a subsequent explicit call to "Close" nor an implicit call from Destroy should actually do anything when they call "DoDisconnect"...
procedure TADOConnection.DoDisconnect;
begin
if Assigned(ConnectionObject) then
begin
while InTransaction do RollbackTrans;
ConnectionObject.Close;
end;
end;
EXCEPT... despite my endeavours, the Connection is still closed in the Destroy, and this is because setting "aAdoConnection.ConnectionObject := nil" has zero effect...
procedure TADOConnection.SetConnectionObject(const Value: _Connection);
begin
CheckInActive;
if Assigned(Value) then *** !!! ***
begin
OleCheck(ConnectionPoint.UnAdvise(FConnEventsID));
FConnectionObject := Value;
OleCheck(ConnectionPoint.Advise(Self as IUnknown, FConnEventsID));
end;
end;
The previous thread suggested a fix, but it doesn't handle the "nil" situation correctly.
My extended suggestion follows...
procedure TADOConnection.SetConnectionObject(const Value: _Connection);
begin
CheckInActive;
// Unlink events *before* releasing the old connection object
if ( FConnEventsID > 0 ) then
OleCheck(ConnectionPoint.UnAdvise(FConnEventsID));
// Explicitly clear FConnEventsID so the Destructor won't call another "UnAdvise"
FConnEventsID := 0;
// Update the ConnectionObject value
FConnectionObject := Value;
// Relink events *after* assigning the new connection object (if any)
if Assigned (Value) then
OleCheck(ConnectionPoint.Advise(Self as IUnknown, FConnEventsID));
end;
Any comments?
D2006 Update 2 10.0.2558.35231
--
Paul Scott
Information Management Systems
Macclesfield, UK.
.
- Prev by Date: Re: Querying a MS SQL View...
- Next by Date: Re: Querying a MS SQL View...
- Previous by thread: Querying a MS SQL View...
- Next by thread: ADO and SQL2K5 and Speed
- Index(es):
Relevant Pages
|
