> a) Close/kill mean the same thing with a process that is meant to run as a
> service. The process itself knows what to do to terminate gracefully when
> instructed to do so. Close/kill are not the same as "crash". If you have
> something beyond the control of the process that causes it to terminate
> abnormally, such as a dangerous UDF, then the process usually cannot terminate
> gracefully.
>

Killing a process will terminate it gracefully ? Like I said the Firebird is
running as an application. We are not the owner of the machines and they want us
to a certain user to run the Firebird. We can't install any service on the
machines. That's why we are running it as an application.

> b) An application designed to run as a service is expected to be available
> whenever a client requests the service. Whether the service is being run in the
> services space (as when installed as a service) or in the user's space (as when
> installed as an application), it still knows how to shut down gracefully.
>

I already know all that. Stopping a service can terminate gracefully. I built
some applications running as service in the past.

>>Because I don't know if all the requested actions have been done by
>>Firebird. So killing the process while Firebird is working is not a
>>good idea.
>
> That is true whether you are running Firebird as a service or as an application.
>

I know, but at least like you said, it can be done gracefully (like doing
rollback , closing the connections or whatever need to be done).

>
> gfix is itself an application, a set of tools that operates on databases. It
> doesn't operate on other processes. When you want to close/kill the server
> process (whether service or application!) you need to shut down the databases
> FIRST. When a database is successfully "shut down" it is flagged "offline" in
> its header. The server process will not accept any new connections or allow any
> new transactions to start from ordinary users while the database is flagged
> offline.
>

But the Firebird still running right ?

>
> Firebird 2 gives you a number of different shutdown states - see the release
> notes. If you are going the stop the Firebird server process then you want to
> specify the FULL state.
>

So at least I could shutdown the database and terminate the Firebird process.

>
> The gfix -shut command takes a timeout value in seconds. When you are going to
> shut down a database, you should send a message out to all the users announcing
> that it is going to happen and instructing them to commit all changes and log
> out. How you do this is up to you - the Firebird server process doesn't have a
> way to communicate with them.
>

being a 3-tier application this would be a little trickie.

>
> So why do you have to run the Firebird server as an application? You are
> forcing the site to keep the host machine open and logged in as Administrator
> even at night when you don't know who is around.
>

I know but this is something I can't control. I have to deal with that. But
again the user used for that doesn't have full rights.

>>> The users are 3-tier.
>
> That's another strong reason NOT to run the Firebird server as an application.
>
> But - if it's 3-tier then the clients aren't connected to the database, are
> they? This is the place everything is controlled, including knowledge of any
> live attachments...why not put the shutdown messages and operations there?
>

No only the server part of the application.

>
> You have an unknown number of people working late, using services that are
> insecure....
>

It's still done securely but not controlled by me.

>
> Problems get to be complicated when there's not enough information.
>

Sorry I can't give you more. I thought this was easy.

> Running a Firebird server -- and indeed your application server -- as an
> application is justified if the host machine is Win98, since it doesn't support
> services. It's justified (maybe) on a stand-alone system where there might be
> reasons why the embedded server can't be used. But here you have a 3-tier
> architecture so we are not looking at a stand-alone system...
>

I know it is a bit complicated. I built this to be run as a service at the
beginning and also an embedded version but because of all the restrictions I had
to built it that way.

>>> -- you can test whether anyone is logged in to a database by
>>attempting to rename the database file. If it works, then nobody is
>>logged in and the database is *already* shut down. You can just go
>>to Task Manager and stop the Firebird process.
>>>

This is what I think right now.

>
> You can't rename a file if it is open. A database file is open if there is at
> least one client attached. With a 3-tier setup, the jury stays out. Maybe the
> application layer stays connected constantly...in which case, only that
> application "knows" whether it has any live clients and the "renaming" trick
> won't work until the application tier is shut down (closed/killed, choose your
> own word!)
>
> If a database client gracefully closes its attachment then what happens on the
> disconnection request depends entirely on what the application does in response.
> Maybe it rolls back any uncommitted work, or commits it. If the application
> doesn't do either, then the Firebird server would eventually treat those
> transactions as "dead" and clean them up. Whatever happens, they won't be
> picked up in future and treated as though they were not dead.
>
>>That could explain why I can an error message when the users
>>shutdown their Windows. A message say that there is still users
>>connected to Firebird and don't want to close.
>
> "Users"? Does this mean clients of the application tier? (which would be
> STRANGE!)
>

Like I said, the Windows user. The Windows user receive this message from
Firebird when he wants to shutdown Windows.

The Windows user needs to click terminate to be able to shutdown Windows. This
might be because I am running Firebird as an application.

> It does look as though your application tier is providing some level of
> marshalling protection. If you're not the author of the software then it does
> seem that you need to consult the author and find out how things work in that
> setup....maybe a graceful exit is already built into that application layer and
> you just need to find out how to work it?

I am the author of the software. I connect my server application to the database
only when needed and use the commit/rollback when needed.

BTW, you and Firebird team did a great job.