Norman Dunbar wrote:

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

You're absolutely right. I should do that rather than bitching. I will
try to figure out how to do that.

>> 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.
>
>

I can see where that would be a problem, but I don't use much in the way
of FKs because of the all the problems reported by other people who
couldn't restore their database because of FK consistency errors.

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

Agreed, but I'm not a bank and a couple of dropped records would be way
better than no records at all for my situation.

>
> 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?
>

Definitely a bug of some kind but I have expounded on that in another
recent email. :)

> 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!
>
>

I always use -create and save the original database before recovering
whenever possible. But sometimes, all you have is the backup. When the
restore fails for some silly reason in those situations you rapidly get
the point where you want to take a sledge hammer to the server and take
up growing flowers or some such as an alternate career path.



[Non-text portions of this message have been removed]