Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to restore "non valid" data and constraints [CORE1030] #1447

Open
firebird-automations opened this issue Nov 29, 2006 · 6 comments
Open

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Jorge Andres Brugger (jbrugger)

Votes: 6

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

nbackup does what you're talking about

@firebird-automations
Copy link
Collaborator Author

Commented by: Jorge Andres Brugger (jbrugger)

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 11363 ] => Firebird [ 14950 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

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

@firebird-automations
Copy link
Collaborator Author

Commented by: Philip Williams (unordained)

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?

@firebird-automations
Copy link
Collaborator Author

Commented by: sboyd (sboyd)

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant