Thanks, again, Helen:

All really good comments.

I agree that it should not be necessary to stop a service. Most of the
time in my own development, I am changing the database name as I use
various test databases. Sometimes, Windows will not let me rename. I
found that simply opening the services dialog and restart FBGuardian,
works. Thus the idea with the Stop/Start service.

In my code leading up to doing an automated, end of application,
backup-restore for the user every 15 backups, I do do a forced shutdown.
That was there and we still had this issue. In that same routine, I go
through all connections and shut them down.

The Tech Support guy does not know anything about using a database and
he definitely does not do any DB monitoring or use of DB admin tools
(God knows I've tried to get him to!) He says this particular issue of
not being able to rename came up on his and one other user's brand new
lap top. (Something about that?)

I use a routine to test if the file is in use. It is a variation of
trying to open the file exclusively. That is what fails, but if it does
the file rename would fail anyway.

Again, I want to restate that this is a Windows desktop application with
a single user. I have FB server loaded on each system, but it is on the
same machine. I am using IBOAdmin, which as far as I know simply sends
API calls to FB, so it should be similar to GBAK.

What did work for these two systems was to simply copy the DB file to
another file name, then restore to the same DB. My original code tried
to rename the current DB, then restore to a new file with the original
DB file name.

Curiously, if I used the command console to rename/delete files it had
no problem. (as long as I shut down the database)

Chuck

> At 08:39 PM 6/04/2012, Chuck Belanger wrote:
>> Hello:
>>
>> I am using IBOAdmin components with IBO 4.8.7 in Delphi 2007 with FB 2.5
>> server all on a local drive, single user system. What I am trying to do
>> is make a restore by renaming the database then restoring to the
>> original file name, so not as to overwrite the database.
>>
>> The problem is that in order to rename the DB file, I found that I have
>> to disconnect then stop the service, rename, then restart the service
>> then do the restore.
> It should not be necessary to stop the service. A database shutdown is all it takes.
>
> Since you are using Superserver, we can eliminate the possibility of Guardian + Classic giving rise to zombie connections. So what it gets back to is that a thread is holding the database file open after "the connection you know about" has been closed. This might well be a garbage collection thread taking advantage of the idle time to do its stuff. A shutdown -force should be sufficient to terminate this asnd release the Superserver's write lock on the file.
>
> Don't overlook the possibility that this "tech support guy" is simultaneously using your app along with other tools you don't know about to connect to this database...think of a monitoring or admin application.
>
>> I test to see if the DB file is in use by any
>> process (the FB server) and then do the renaming. But, although this
>> works for all 5 systems that I have and use for testing, I have one user
>> on whose system, the DB file even after stopping the FB service, shows
>> the DB file is still in use, which stops the restore since I am trying
>> to avoid writing over it.
> As I mentioned earlier, stopping the service is (or should be) an overkill. A database shutdown dissociates the database from the server except for the particular conditions allowed for the shutdown type.
>
>> Does anyone have a suggestion on how to restore and change file names
>> without running into "file is in use by another process" type error.
> Note that some tools open a database file without a client connection, even gstat -h, nBackup and lockprint from FB's own tool set. External backup programs get their own locks on files, sometimes even overriding write locks that have been secured by a running application, such as the Superserver executable. It would be worth investigating what else this tech support guy might be doing on his setup, that could be entailing the database file.
>
> Helen
>
>
>
> ------------------------------------
>
> ___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
> ___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info papers,
> keyword-searchable FAQ, community code contributions and more ! Yahoo! Groups Links
>
>
>
>