Issue Details (XML | Word | Printable)

Key: CORE-1714
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Minor Minor
Assignee: Unassigned
Reporter: Paolo Fainelli
Votes: 1
Watchers: 3

If you were logged in you would be able to see more operations.
Firebird Core

restoring a 1.5 database gbak give error: "value exceeds the range for valid dates"

Created: 29/Jan/08 01:11 PM   Updated: 30/Mar/16 02:33 PM
Component/s: None
Affects Version/s: 2.1 Alpha 1, 2.1 Beta 1
Fix Version/s: None

Environment: winXP sp2 - superserver
Issue Links:

 Description  « Hide
I received this error restoring some production databases from fb 1.0 or fb 1.5. Gbak work well under 1.5 and 2.0 version. If required i will send a database with this problem

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 29/Jan/08 01:24 PM
The error means to say that some column has an invalid date value (outside the supported range). Prior to v2.1, it was possible to store such invalid values in the database, but now it's prohibited. A verbose output should point you to a problematic table.

Stephen Gowen added a comment - 09/Oct/08 12:49 PM
I received the same error for a database that was working quite happily with Firebird 2.04. When I upgraded to Firebird 2.1.1 I was then unable to perform a select from the table containing the relevant field. This stops my application from working as in the table is queried each time that the application opens and this failing stops my application from showing any data. I even tried doing a gBak -restore on a backup of this database but this again failed with the "value exceeds the range for valid dates" error. This I eventually found to be down to a date field that was left in the table but not used. This would stop all of my customers from working with Firebird 2.1.1 until they received an executable from me which either set this field to a valid date or null or dropped this field.

Would it not be a better solution to either in the database engine or the gBak -restore to set any fields that would result in this error, to a predetermined or null date value.

Dmitry Yemanov added a comment - 24/Oct/09 05:24 PM
The current behavior is intended and is unlikely to be changed.

Andrei Kireev added a comment - 05/May/11 11:02 AM
Just in case it would be useful for someone. We put instructions on how to deal with the problem here:

the page is in russian.