> >your previous message didn't say the first SYSDBA connection was
> lost. It shouldn't be. Only non-SYSDBA, users will be prevented
> from re-connect. And they will also be disconnected afte rthe
> timeout. Their open transactions will be rolled back.
> >
> >For this procedure to work as you expect, make the first
> connection a non SYSDBA connection
> >
> >
> Yep, I created another Firebird user account "Guest" with password
> "OtherUser" on my local Firebird server. Here is my new script:
>
> Prompt 1:
> isql "localhost:C:\Program Files\Firebird\Firebird
> 1.5\examples\Employee.fdb"
> -user Guest -password OtherUser
>
> Prompt 2:
> gfix -shut -force 0
> "localhost:C:\Program Files\Firebird\Firebird 1.5\examples\Employee.fdb"
> -user sysdba -password masterkey
>
> gbak -backup
> "localhost:C:\Program Files\Firebird\Firebird 1.5\examples\Employee.fdb"
> "C:\Program Files\Firebird\Firebird 1.5\examples\Employee.gbk"
> -user sysdba -password masterkey
>
> gbak -replace_database
> "C:\Program Files\Firebird\Firebird 1.5\examples\Employee.gbk"
> "localhost:C:\Program Files\Firebird\Firebird 1.5\examples\Employee.fdb"
> -page_size 4096 -user sysdba -password masterkey
>
> gfix -online
> "localhost:C:\Program Files\Firebird\Firebird 1.5\examples\Employee.fdb"
> -user sysdba -password masterkey
>
> And the error after calling gbak -replace_database persists:
> gbak: ERROR: could not drop database localhost:C:\Program
> Files\Firebird\Firebird 1.5\examples\Employee.fdb (database might
> be in use)
> gbak: Exiting before completion due to errors
>
> On top although I can't use the connection of Prompt 1 anymore as soon
> as I have shutdown the database (with gfix -shut -force 0 in Prompt 2),
> the Firebird Server properties still shows a 1 for "Number of
> attachments" and "Number of databases". So the connection hasn't really
> been killed by the "forced" shutdown. Bummer!
>
> Any ideas how I could achieve what I am after (e.g. killing all
> connections, backup & restore exclusively)?!? Thanks for a short answer
> in advance.
>
> Salut,
> Mathias

I must say, I've always avoided this methodolgy so I can't vouch for it personally. I can see what you need to do and I have always convinced my clients that remote admin of this sort is not optimum.
I prefer this method (but it's not remote-able)
1. shutdown database (if operating) if out of hours, then stop FB service.
2. rename db file. (only achievable if noone is connected) if this fails then someone is connected.. fix this issue.
3. turn service on (if off in 2)(no file available to users - they error out if they try to connect but you've warned them well in advance of maintenance outage)
4. backup and restore to yet another name (noone knows the name and can't connect til you're ready)
5. rename file to original filename if no errors restoring (this action is atomic in nature)

All other maintenance of backup / test restore nature is carried out while people are connected. This (above) operation is only done once a year. I argue they can pay me to do it once a year. And for this reason it's not worth me putting it into the client application.

Alan