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

Unrestorable backup [CORE1748] #2173

Closed
firebird-automations opened this issue Feb 18, 2008 · 13 comments
Closed

Unrestorable backup [CORE1748] #2173

firebird-automations opened this issue Feb 18, 2008 · 13 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Igor Lobov (ivl)

Is duplicated by CORE2458
Relate to CORE2696
Is related to QA540

Attachments:
test.sql

I have table with NOT NULL fields with records.
If some count of NOT NULL fields are clear I can create backup file without any errors, but can not restore it.

I attached simple script of example database.

Commits: 218f419

@firebird-automations
Copy link
Collaborator Author

Modified by: Igor Lobov (ivl)

Attachment: test.sql [ 10773 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @cincuranet

IMO it's not bug, it's by design. You have to add column and if it's NOT NULL, you have to fill it with some data yourself.

@firebird-automations
Copy link
Collaborator Author

Commented by: Igor Lobov (ivl)

Maybe it is not a bug, but it is potential hole in Firebird backup system.
I think that such defects of database must be found before or during backup process.
Prohibition to add NOT NULL fields without default values could be a solution of this problem.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

You *can* restore such a backup (at least since v2.0) using a "-no_validity" switch.

@firebird-automations
Copy link
Collaborator Author

Commented by: Csaba Lassán (cslassan)

Dear All, in my opinion this serious bug is related more to the server core itself than the backup utility, because no one shall add "not null" columns to populated tables. If there is a way to do it, that means one can make a self-conflicting data definition!
This bug is in my 2.1.0.17735 server too.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

While this can be treated as a bug, this is actually the intentional behavior inherited from the very old InterBase versions.

@firebird-automations
Copy link
Collaborator Author

Commented by: Csaba Lassán (cslassan)

Dear Dmitry, may Codd bless You :D

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue is duplicated by CORE2458 [ CORE2458 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue relate to CORE2696 [ CORE2696 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 Alpha 1 [ 10331 ]

assignee: Adriano dos Santos Fernandes [ asfernandes ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Link: This issue is related to QA540 [ QA540 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

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

2 participants