Paul,

>> P> The next step is to take whatever action is
>> P> needed to kill the server - this is platform dependant.
>>
>> Yep - and this I believe differs between applications and services. If
>> I issue NET STOP Firebird, or equivalent StopService() API call, I
>> know that the Firebird service has a chance to terminate gracefully.

PR> Er - no. This is an O/S level api call and I don't believe it does a check
PR> to see what the service is actually doing.

It doesn't, directly, but it sends a control message to the service
*asking* it to stop itself (assuming we are talking about the same API
call, which is ControlService() and not StopService() as I wrote
before - StopService() happens to be just a wrapper in my library).
I don't know if ControlService is used and how does Firebird server
react to the SERVICE_CONTROL_STOP control code, but in theory it could
be much less brutal than TerminateProcess().

PR> Similarly, the code behind
PR> instsvc just makes the relevant O/S level api calls. It doesn't check
PR> whether there are connections. So, there is no functional difference
PR> between this and killing a process (at least as far as Firebird is
PR> concerned.)

It depends on how Firebird reacts to that control message. Can you
perhaps point me to the location in the sources in which the behaviour
of the server as a service is coded?

PR> Of course, this is wrong behaviour, but it is how it has been since IB5
PR> (and probably continues in recent versions of IB.)

I'm doing TerminateProcess() for the time being. But if there's an
opportunity to tidy things up in this area then let's catch it. ;-)

Ciao
--
Nando mailto:nandod@...