Zeoslib Portal

Addendum: If you want your database conenctions to survive a short disconnect, you might want to do experiments with the Zeos Proxy Server that is included in Zeos 8. You should know that I never tested it with OLEDB and MS SQL Server though.

I get the Error1, in the error handling, when ZQuery.Open.
Error2 also appears later.

cause in the source text ...
ZAbstractRODataset.pas
function TZAbstractRODataset.CreateResultSet(const SQL: string; MaxRows: Integer): IZResultSet;
Line 3516 else Result := Statement.ExecuteQueryPrepared;

ZAbstractDataset.pas
function TZAbstractRWTxnUpdateObjDataSet.CreateResultSet(const SQL: string; MaxRows: Integer): IZResultSet;
Line 1072: Result := inherited CreateResultSet(SQL, MaxRows);

ZDbcOleDB.pas
procedure TZOleDBConnection.HandleErrorOrWarning(..)
Line 916: then Sender.ReleaseImmediat(Sender, EZSQLConnectionLost(Error))

ZDbcOleDBStatement.pas
procedure TZOleDBPreparedStatement.ReleaseImmediat(const Sender: IImmediatelyReleasable; var AError: EZSQLConnectionLost);
Line 1861: inherited ReleaseImmediat(Sender, AError);

procedure TZAbstractOleDBStatement.ReleaseImmediat(..)
Line 686: ClearCallResultCache;

procedure TZAbstractOleDBStatement.ClearCallResultCache;
Line 547: for I := 0 to FCallResultCache.Count -1 do

here is => FCallResultCache=nil

Norbert

Hello Norbert,

I added the SQLState 08S02 to the list of SQLStates that generate an connection loss error. Could you please check if this works for you?

Best regards,

Jan

Hello Jan

that only partially helps. "Zquery.Open" now comes with ZConn.OnLost

The first error (Error1.jpg) still occurs at exactly this point (See attachement) ...

ZDbcOleDBStatement.pas
procedure TZAbstractOleDBStatement.ClearCallResultCache;
Line 547: for I := 0 to FCallResultCache.Count -1 do
=> because the FCallResultCache is NIL.

But the error only comes here:
ZAbstractRODataset.pas
procedure TZAbstractRODataset.InternalInitFieldDefs;
...
=> ResultSet := CreateResultSet(FSQL.Statements[0].SQL, 0);

Cause: ZQuery.GetFieldNames()
Since this is usually the first call in the dialog.

Norbert

marsupilami wrote: ↑06.07.2022, 08:08But I have doubts wether this will fix your problems.

Yep. Didn't help :(

aehimself wrote: ↑09.07.2022, 18:35

marsupilami wrote: ↑06.07.2022, 08:08But I have doubts wether this will fix your problems.

Yep. Didn't help

Just to be sure - it is the thing over here? viewtopic.php?f=37&t=152220

nlanger wrote: ↑09.07.2022, 13:05 that only partially helps. "Zquery.Open" now comes with ZConn.OnLost

So that works as it should now.

nlanger wrote: ↑09.07.2022, 13:05 ZDbcOleDBStatement.pas
procedure TZAbstractOleDBStatement.ClearCallResultCache;
Line 547: for I := 0 to FCallResultCache.Count -1 do
=> because the FCallResultCache is NIL.

I fixed that one. Since FCallResultCache is set to nil in the end we also can check if it already is nil.

nlanger wrote: ↑09.07.2022, 13:05 But the error only comes here:
ZAbstractRODataset.pas
procedure TZAbstractRODataset.InternalInitFieldDefs;
...
=> ResultSet := CreateResultSet(FSQL.Statements[0].SQL, 0);

Cause: ZQuery.GetFieldNames()
Since this is usually the first call in the dialog.

I am not sure what to do here. Is this fixed by the other fix?

If there are other problems: Could you try to create a small test case?

marsupilami wrote: ↑11.07.2022, 08:09Just to be sure - it is the thing over here? viewtopic.php?f=37&t=152220

Yes, that is the nasty one. Reading the whole thread back makes it funny how much progress was already made compared to the initial state.

Anyway, I'll jump out from this thread as I'm being completely offtopic here. I was just hopeful, that's all :)

First => ZQuery.GetFieldNames()

No, that's the same error, I wrote the process upside down.
I'll try the new version later.

Norbert

Hello Jan

Yes, now there are no more access violations when changing the WLAN. Everything perfect.

Thanks
Norbert