ZConnection.PingServer

[seawolf]

function TZConnection.PingServer: Boolean;
var
LastState : boolean;
begin
// Check connection status
LastState := GetConnected;
if FConnection <> nil then
begin
Result := (FConnection.PingServer=0);
// Connection now is false but was true
if (not Result) and (LastState) then
// Generate OnDisconnect event
SetConnected(Result);
end
else
// Connection now is false but was true
if LastState then
SetConnected(false);
end;

[mparak]

Dear SeaWolf,

I am very keen to use your code, but need help in applying the patch.
If you could be so kind to tell me how exactly one goes about adding this to the Tconnection object.

Regards

Mo

[seawolf]

Sorry about explanation .. basically open ..\src\component\ZConnection.pas
and substitute

function TZConnection.PingServer: Boolean;

with the one posted.
How it works ... when PingServer is called it verify if Connection was created or not. Then check if connection is true or false. If it is false and Connected is true then raise OnBeforeDisconnect and OnAfterDisconnect events (by this way Connected is set to false).

Tested with Postgres 8.3.6

[mdaems]

Seawolf, what's the advantage of your version over the current implementation? Do I understand right that the difference is that this code on a failed ping also calls the events that are fired on normal disconnect calls? Does it also close datasets and so on when the ping fails?

[seawolf]

This implementation solve 2 problems:

1. if Connection = nil (i.e. client never connected to the server) and pingserver is called an exception is raised.

2. If Connected = true but ping returns false, connected stay true .. I think would be better if Connected is set to false and raised OnAfterDisconnect and OnBeforeDisconnect events. So Connected property is set properly

About the dataset I've never checked, so tomorrow I'll do.

[mdaems]

seawolf,

Shouldn't Ping and PingServer be synonyms?

Seems to me the original versions didn't have different behaviour. When we aply your patch they are different again, but is there still a use case for the old approach?

Always talking about Zeoslib 7. I don't want a behavioral change in 6.6.

Mark

Update : SVN rev. 615