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
Comments
Commented by: @dyemanov nbackup does what you're talking about |
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. |
Modified by: @pcisarWorkflow: jira [ 11363 ] => Firebird [ 14950 ] |
Commented by: @livius2 I agree with reporter I'm grate that this was finded be raporter |
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? |
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! |
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.
The text was updated successfully, but these errors were encountered: