At 08:35 AM 19/04/2006, you wrote:

> > Are there specific deployment conditions at the problem sites, where
> > you are trying to run the backup from the same application space as
> > the main app and/or the main app is using a Windows local connection?
>
>I'm sorry Helen. I don't understand your question. This is basically
>a single user application and everything is on the local machine. The
>Firebird service runs locally and the application is local.

I mean, tell us how the application makes the local connection, out of

1. "Windows local" (IBO: protocol cpLocal, Nil in Server property)
2. Local loopback server (protocol cpTCP_IP, localhost in Server property)
3. Local WNET (protocol cpNetBEUI, local machine name in Server property)

The reason the fbk file is not being closed is that the gbak process
needs to complete and then close its connection to the database. If
that doesn't happen, the fbk file is still exclusively locked by the
gbak process and will remain so until the gbak process
disconnects. On sites where the PC is running 24/7, this symptom is
likely to be hiding an ever-increasing number of unclosed connections.

>Transactions in the application are set to AutoCommit.

That's not relevant to service manager/gbak. SM invokes gbak, which
runs in its own snapshot transaction and ends that transaction when
the backup is done, regardless of what's happening elsewhere.

>Out of the 800+ locations running this application, we're seeing about 10-15
>support calls a week related to this problem. The calls appear to be
>random and I can't tie it to any one OS or customer's setup. However,
>the culprit is always a FBK that is open when we try to delete it or
>rename it.

Sure; it's possible that this is caused by the service manager
running gbak, which is invoking its own instance of the Windows local
client across the same application space as the main app. So it will
be necessary first to review how the main app is connecting to the
database: if it's using cpLocal protocol then the answer is right
there; if it's using cpTCP_IP or cpNetBEUI then there is more to
explore, like how well your application code is isolating the service
manager calls from the data access application.

So you're looking at one and possibly two things to fix in your
application code. From here, this problem belongs in the IBO list...

./heLen