Evening Steve,

> The MIN date in the table is 0/00/00 which would appear to be the problem. I got rid of that and everything works. Thanks very much for your help.

Welcome. I wonder if that's something that has changed between FB 1.5
and FB 2.1? Anyway, I'm glad you got it sorted.

> Brings me to my favourite Firebird rant though.
>
> 1) If it is going to tell me about bad data in a column, tell me the name of the column....

I agree. Why not consider raining it as an enhancement request/bug report?

> 2) For piddly stuff like this, gbak should be able to just warn me and carry on.

Maybe an option, but what if the columns it had trouble with were part
of an FK relationship - further down the line you'd probably get other
errors about missing parent records, for example.

> There is no way a seemingly good back up should ever be un-restorable

(barring corrupt media).
True, but I think I answered/opinionated (!) on that in another email. ;-)

> At some point, you just have to accept that the data isn't as clean as

it should be and get

> on with the job at hand, which is restoring the database.

I really hope my bank doesn't do that! ;-)

> I've lost track of the number of times I have tried to recover from a back up only to find out
> that the back up is un-restorable for some silly reason and had to

resort to writing a bunch of

> tools to piece the database back together. Not fun!

If that's the case, then maybe you are hitting a bug that needs to be
reported? Otherwise, I'd start having my suspicions about the exact
cause of said unrecoverability. Especially if it has happened in the
same manner more than once.

Can you remember any of the faults that stopped you recovering a database?

Equally, the use of a recover with "gbak -replace_database overwrite"
doesn't come recommended as the first thing that happens is that your
database file(s) are wiped. if the rest ofn the restore goes wrong, no
more database!

> Just my $0.02.

Thanks.

Cheers,
Norman.