At 11:18 AM 10/06/2009, you wrote:

>Thanks for your reply. But this has happened once two days ago without me crashing out of isql. Is there anyway to recover short of rebooting the computer?

From Firebird's POV, you shouldn't have to reboot the computer at all. But it's really unclear where you're "at" with respect to the abandoned filesystem locks on the database file. Maybe they won't go away without a reboot - I just don't know.

When you talk about "applications", do you mean local programs connecting directly to the database or client applications requesting TCP/IP connections via the xinetd daemon? What are you using as a connection string in each of these cases? What error messages appear? What can you see in firebird.log?

>(I tried using gfix to rollback uncommitted transactions but that did not help).

Gfix can't roll back uncommitted transactions, except limbo transactions. Limbo transactions are two-phase transactions that have been left in a partly committed or rolled-back state by interruption of a multi-database transaction. If limbo transactions are the issue, then you should be seeing exception messages to that effect. If that's your situation, then you will have to deal with the limbo transactions in the other affected databases too, to resolve it.

Just for a few reality checks:

Is this database located on a physically local hard disk, i.e., one that is wired directly to the machine running Firebird?

Is the newly installed aliases.conf valid for your database paths?

Do your applications try to do things at connection time that are no longer legal for non-privileged users?

If your apps are connecting as xinetd clients, have you checked:

-- whether xinetd is actually running?

-- whether the 'firebird' user has privileges to the database file? And/or that the (local) user is a member of the firebird group?


Can't think of anything else for you to check. The day is young, though.

./heLen