Jason, Ed. I had a similar problem! 4.9.14. (9 thru 18) this is my patch. Hopefully it will point you in the right direction!

This is my patch (as usual tentative and trial-and-error:ish)


procedure TIBOQueryDataLink.ActiveChanged;
begin
//if FIBDataset.Active then
if FIBDataset.Active and // *** DANYCHANGE
not FIBDataset.IB_Connection.ConnectionWasLost and // *** DANYCHANGE
not (FIBDataset.IB_Connection.ConnectionStatus in [csDisconnected, csDisconnectPending, csDropPending]) then begin // *** DANYCHANGE
FIBDataset.RefreshParams( true );
end;
end;

At the same time I was implementing lost/reconnection handling and had some problems with an exception being thrown (twice? memory fails) and the fix for that was:


procedure TIB_Transaction.API_Commit;
var
ii: integer;
begin
if not Started then Exit;
with IB_Session do
begin
if ClientMonitorHooksIn then
OutputToMonitor( 'Commit Transaction: ' + GetFullIdentName( Self ));
errcode := isc_commit_transaction( @status, PtrHandle );
// if errcode = isc_no_meta_update then begin
if errcode <> 0 then
begin
if not CheckLostConnection then
begin
for ii := 0 to ConnectionCount - 1 do
Connections[ ii ].FlushSchemaCache;
if Started then
errcode := isc_commit_transaction( @status, PtrHandle );
end
else
errcode := 0; // *** DANYCHANGE - no use to HandleException below...
end;
if errcode <> 0 then
begin
TimeOutProps.FDisableCheckOATFromError := true;
HandleException( Self );
end;
end;

Please not that this may be totally OT, but a gut feeling is that transaction/destruction/etc-handling is somewhat related here.

HTH and as always an apology for not checking into the yahoo often enought.

/Dany