> After a week or so on the server there may be 20 or so FB
> classic processes sitting there waiting for me to kill them.
>
> FB v1.5 classic running on Windows 2000 SP4
>
> Note that, for various reasons, the classic executable
> has been renamed. I am wondering if this may be the cause?
> (Seems unlikely but thought I should mention it.)
>
> Anyone else see this?

It can (apparently) happen if you have guardian installed alongside
classic server. The most recent versions of 1.5 don't offer you the
check box to install guardian if you select classic server, but they
used do.

It doesn't do anything other than restart the service if it crashes
which you can do through services.msc anyway. Unless you are
installing on 9x you don't need guardian at all.

>
> Are there any tools out there that make it easier to try and
> manage a FB classic v1.5 install? (For example to extract the
> process-to-ip-address-to-ip-addess information, even better if
> it could eventually work out the terminal server session and
> user that is using the process. AFAICT all the information is
> available, it just needs and tool to put it all together.)

I am pretty sure there is some stuff in the 2.1 monitoring tables that
may be useful for this purpose, but not in 1.5.

If you have source code for the clients, you can devise a crude but
effective tracking into the database itself.

Write a UDF that returns the current process ID to Firebird. It is a
pretty simple call to the Windows API:
http://msdn.microsoft.com/en-us/library/ms683180(VS.85).aspx

You can create two new tables in your database, something like:

AUDITCONNECTIONDETAILS
(
ID BIGINT,
CURRENTCONNECTION BIGINT,
AKEY VARCHAR(20),
AVALUE VARCHAR(100)
);

Your client could then be modified to upon establishing a connection:
1. Start transaction
2. Insert some records into AUDITCONNECTIONDETAILS for anything that
can help you identify it. eg, PID from UDF call, windows username from
client, executable path, IP Address, date and time, PID for client app
etc.
3. Commit transaction

Prior to disconnecting, do some cleanup:
1. Start transaction
2. Delete from AUDITCONNECTIONDETAILS based on CURRENT_CONNECTION
3. Commit.

Then if you notice an orphaned process, inspect the process ID from
task manager and perform a lookup in AUDITCONNECTIONDETAILS to find
the PID (eg. where AKEY='PID' and AVALUE=1234).

You can then see clearly the what started the connection.

Adam