--- In firebird-support@yahoogroups.com, "kranas97" <kranas97@y...>
wrote:

>
> Hi Helen. Thanks again for your answer.
>
> I know that you are a very experienced user (judging from
> your many posts) and I now I'm just a starter to firebird
> (two - three months experience means nothing). Yes I have
> read the interbase op guide but also trying to find the
> best interface for BCB (tested zeos, IBX ended up with ODBC)
> and do the actual developement in a four months period.
> Wasn't my choise but the other alternative given to me
> was MS Access !!
>

She may know a thing or two. <plug> Her book is probably the most
recommended resource for learning Firebird <plug>

> I believe what you say that -replace is a bad
> option but as I said in my post the application
> will run in a place with users who don't now
> what is a command prompt, a database or even speak English.
> I'm not get paid for the application (I'm not complaining here)
> and I wont be available all the times to support them.
> I can instruct them, once a day to push a button to perform
> a backup (online) which I keep depending on the day of the week
> the month and the year.

The problem with -replace is that if the backup you are trying to
restore from didn't correctly and completely back up, you have lost
your entire database and can not recover it. It is a real possibility
for a backup to fail, particularily if you are backing it up to an
external media or over a LAN.

> But In case of emergency I can't figure out an automated way
> to perform a safe restore. I have developed an app which first
> check for users connected, if no-one is ,shuts
> down the server, perform a backup, and restore (yes with replace)
> from their last backup and take the database online again. I use
> IBPP and BCB6. I couldn't use any of the ready tools out there
> cause either are too complicated for my users, or in different
> language. Thats way I keep asking about when gfix returns. I want
> to be sure that the database is realy shutdown.
>

As you have already been advised, restore the file to a different
location, and if you have no problems connecting to it, rename the
old one and copy the new one into the main location.

Removing the entry from aliases.conf should be enough to prevent
connections during a backup / restore (have a separate alias for
this).

> Just one more thing
> You said "When you have a corrupt database, no-one is connected to
> it"
> Does this mean that if a database is corrupt you CANT connect?
> Because during my development I had a case where after
> a few DDL statements I had a strange problem:
> I couldn't define a foreign key for a table (from what I remember
> the message was that the table was in use) and only SYSDBA
> was connected (and YES only one time).
> gfix returned no error (with full validation) and I could connect
> from my app to the database and work without no problem.
> Shutting down - restarting or even backing up and restoring
> didn't solve the problem (backup and restore worked fine).
> No network - no connections - just me (SYSDBA) and firebird.
> Was that a corrupted database or not? (I believe I have that
> database somewhere if you are interested).

No corruption, that is normal behaviour.

You will probably find that your transaction read or touched that
table prior to the change. Running a commit is all you needed to do.
You can't define a foreign key while the table is in use, because
that would confuse things (would the older transactions know about
this structural change?)

As a rule of thumb, for structural changes, you should be the only
user, and commit just before and after you make any changes.

>
> I recreated the database from my original script (I prefer
> to write the DDL's that way) and then I was
> able to define the foreign key with no problem.
>
> I just want to point out that you can work with
> no problem with a corrupted database for a long time (until it
> crashes on your face ofcource). So how to test if the restored
> backup is ok automated?
>

You will usually know. Tables missing or empty, unable to connect
etc. The problem with -replace is the first thing it does is to drop
(ie delete / destroy / wipe out / kill / erase / send to dev/null)
the old database. If you discovered the backup file was corrupt, it
is too late to do anything about it.


Adam