| Subject | Re: Error loading DB using FB 2.1.3 |
|---|---|
| Author | sboydlns |
| Post date | 2010-08-10T16:26:45Z |
--- In firebird-support@yahoogroups.com, "Dunbar, Norman (Capgemini)" <norman.dunbar.capgemini@...> wrote:
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. That would be so much nicer than having to guess or do a data analysis on every column in the table. There are 20 some dates in the LOADS table. It would have been nice to know which one to look at.
2) For piddly stuff like this, gbak should be able to just warn me and carry on. There is no way a seemingly good back up should ever be un-restorable (barring corrupt media). 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'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!
Just my $0.02.
>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.
> You don't have any dates in your database that are greater that December
> 31 9999 or less than January 1 0001 do you? I assume the lowest time
> portion of the date is 00:00:00.0000 and the maximum is 23:59:59.9999.
> This would be in the LOADS table.
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. That would be so much nicer than having to guess or do a data analysis on every column in the table. There are 20 some dates in the LOADS table. It would have been nice to know which one to look at.
2) For piddly stuff like this, gbak should be able to just warn me and carry on. There is no way a seemingly good back up should ever be un-restorable (barring corrupt media). 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'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!
Just my $0.02.