Issue Details (XML | Word | Printable)

Key: CORE-1030
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Jorge Andres Brugger
Votes: 6
Watchers: 6
Operations

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

Switch to restore "non valid" data and constraints

Created: 29/Nov/06 09:15 PM   Updated: 11/Aug/10 02:26 PM
Component/s: GBAK
Affects Version/s: 2.0.0
Fix Version/s: None

Environment: General


 Description  « Hide
If you backup a database that, for example, contains null in a field defined as not-null, you cannot restore it. You can use "-no_validity" switch, and you?ll loose _all_ your database checks.
I?m proposing to implement a new switch, that enables to restore a database with checks, even if there are "non-valid data" records.
If you can add a "not null" field to a table, even if is automatically set to null when there are records, you should be able to restore that DB from backup with same state. If not, force to define a default value when adding fields.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 30/Nov/06 02:05 AM
nbackup does what you're talking about

Jorge Andres Brugger added a comment - 30/Nov/06 11:21 AM
I'll take a look at nbackup. Anyway, if gbak will continue existing in next versions, maybe my suggestion could be considered, at least the part of "delete only the checks for which data is not valid", and not all in the database.

Karol Bieniaszewski added a comment - 14/Jan/10 01:28 PM
I agree with reporter
This switch should exists or adding not null without default value should raise exception.
Because now we can create "backup" which is not a backup only some useless file which we can not use for restore

I'm grate that this was finded be raporter
i add to my tool auto restore for checking some restoring problems

Philip Williams added a comment - 17/Mar/10 10:41 PM
I've been bitten by this one as well -- it doesn't just drop the few constraints that prevent data from being restored. I don't think that's made clear enough. Once you restore the database and fix the data, how are you supposed to get your constraints back, exactly? How do you even know which fields used to be NOT NULL and which weren't, so you know where to manually fix them?

sboyd added a comment - 11/Aug/10 02:26 PM
And it's not just problems with NOT NULL constraints. I was recently bitten when trying to restore a 1.5.5 database to 2.1.3. There were a couple of date columns that had bogus values and I couldn't restore the database. gbak wouldn't even tell me which columns were in error. It was left as a exercise for the user to do validity checks on all date fields in the table to find out which one was bad. A backup that can't be restored is not a backup!