At 04:57 AM 20/03/2006, you wrote:

>I want to do this from my aplication
>
>
>1: once the client clicks the restore button the program disconnects the
>database (and hopefully all connected clients)

A client can only request to detach its own connection, not
others'. And it is only a request: it is unpredictable how long it
will take for the engine to complete all of the under-the-hood
requests from the client to complete fetching datasets, commit/roll
back transactions, etc.

Then, your button-clicker will need to be SYSDBA and call for a
database shutdown. Again, how long this will take is
unpredictable. A shutdown call can prevent new connections, new
transactions, or both, but if any connections or transactions are
still running after the timeout period, the database won't be
shutdown. You'll need some retry mechanism.

>2: restore the database using REPLACE switch

NO. Never do this directly from a user application or as a
repeatable offence. You should always use the -c[reate_database]
switch, restore to a temporary database (taking utmost care about
ownership!), verify it; and only then rename the shutdown database,
rename the temp database and put the newly created database online.

>3 Bing the database back online
>
>
>
> The problem is that the command "gfix -shut -force 0 -user
> SYSDBA -password masterkey mydb.fdb" does shut down the database,
> but the database can't be rewritten if other clients are still
> connected, its odd for me, cause I expected that a database that is
> "shut down" to have no connected clients, so in this scenario I
> cant rewrite the database (it prompts an error saying "could not
> drop database X, database might be in use" but if I close all
> client applications, then I can make my restore, which is also odd
> since I am disconnecting clients from a disconnected database!

Your shutdown call doesn't put the database into a shutdown state if,
at the end of the timeout period, there are still live connections or
transactions. For a start, a timeout of zero is useless. Make a
timeout of something like 5 minutes so at least there's some hope
that the disconnecting clients will complete their detach requests.

> It seems to me that that a shutdown database still retains
> connections,

No. If it really is in a shut-down state, only a sysdba or an owner
connection will still be live. But if you have ordinary users logged
in as sysdba or owner then its effectively useless trying to shut
down the database at all.

>I need a way to purge all connected clients from the database to
>release the lock on the file so the database can be rewritten
>Can I achieve this programmatically?

Possibly; except DON'T try to use -r[eplace_database] - you'll
regret it - it's definitely a super-DBA tool for use in extraordinary
circumstances. However, most people implement immediate restores,
i.e. backup, restore to temp, verify, renamings, in a batchfile or
cron job with lots of logging.

>Or i am a crazy man that just wrote half a page of BS?

I wouldn't put it quite that way... :-) It does seem that you need
to study OpGuide.pdf somewhat, though, to understand the shutdown
concept and how the -[s]hut switch works. And DON'T ignore the
warnings about using gbak -r.

./heLen