| Subject | Re: [IBO] How to restore and save the original DB file? |
|---|---|
| Author | Helen Borrie |
| Post date | 2012-04-11T23:38:21Z |
At 08:39 PM 6/04/2012, Chuck Belanger wrote:
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.
Helen
>Hello:It should not be necessary to stop the service. A database shutdown is all it takes.
>
>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.
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 anyAs 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.
>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.
>Does anyone have a suggestion on how to restore and change file namesNote 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.
>without running into "file is in use by another process" type error.
Helen