--- In firebird-support@yahoogroups.com, Jorge Andres Brugger
<jorge.brugger@...> wrote:

>
> You can add a field to a table, and set it to "not null", even if that
> table already has data. Ok. Backup that database, and you cant restore
> it because that "not null" field containing nulls. If you use the

switch

> of gbak to skip data validation, you lost _all_ your checks (not only
> problematic ones).
> If live database can contains nulls where it shoudnt be, then backup
> should restore database exactly as there was before backup.
> Or, at least, no restore only that problematic checks.
>
> Maybe you have a better solution? I'm waiting to read it! :)
>

Pick up the toppled bottle rather than mopping it up every time the
floor becomes too wet.

It is indeed a 'gotcha', that one can add a not null field yet fail to
do something about pre-existing data. Until there is a DDL to convert
an existing field to not null though, there is no other option but to
say remember to do an update statement. If such DDL existed, you could
disable adding a not null field. Instead, you add a nullable field,
and attempt to convert it to not null, which would fail if there were
any nulls.

You should always as matter of process test that your backup can be
restored to a temporary location as part of your backup procedure.

In any case, even if you lose all your checks, you should still have
access to your data. Run appropriate DML statement(s) to fix your
data, then pump it using a data pumping tool into an empty database
using something like CleverComponents IBDatapump.

Or if your database is fine, do it in the live one then take a backup
and restore to a temp location until you get no errors.

There is a backup model in Firebird 2 for what you want, something
that backs up the file and restores it 'as is'. It is called NBackup,
and simply makes it safe to XCopy the database. But you don't get the
advantages of a backup-restore cycle.

Adam