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

gbak from FB2.5RC2 can not restore a database to FB 2.1.1 server [CORE2949] #3331

Closed
firebird-automations opened this issue Mar 29, 2010 · 8 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Derryck welas (welas)

Attachments:
test2.5.fdb.zip

When you restore a backup made with fb 2.5RC2 to a running FB 2.1.1 Server

you get this error:

gbak: ERROR:action cancelled by trigger (3) to preserve data integrity
gbak: ERROR: table/procedure has non-SQL security class defined
gbak:Exiting before completion due to errors

i'm using the gbak from FB 2.5 and restore to the remote fb 2.1.1 server.

@firebird-automations
Copy link
Collaborator Author

Commented by: Derryck welas (welas)

example 2.5 backed up database

@firebird-automations
Copy link
Collaborator Author

Modified by: Derryck welas (welas)

Attachment: test2.5.fdb.zip [ 11607 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

This is not a bug!

You have never been able to downgrade a database using GBak from the higher version.

You need to use the 2.1.x GBAK to create a backup of the 2.5 database, then restore to a 2.1 database.

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

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

resolution: Won't Fix [ 2 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Sean, it was possible starting with 2.x (I don't remember whether it was 2.0 or 2.1). Claudio had implemented basic support for this facility, but IIRC it was never documented in depth. But, as this ticket shows, that basic support doesn't cover all situations and v2.5 changes (in terms of security class names) are not backward compatible via backup/restore. I suppose we'll have to live with that fact.

@firebird-automations
Copy link
Collaborator Author

Commented by: @helebor

Sean asked me to comment on this issue, so here goes.

My understanding of the issue is that , officially, it was never possible to take a backup under a server that creates ODS n databases and restore that backup on a server that creates databases of ODS <n.

A long time ago, during the long gestation period of Fb 2.0, in the context of "downgrading" ODS 11 databases to ODS 10, it was discovered that it was possible in some cases, by using a copy of the Fb 1.5 gbak program in a running Fb 2.0 server. "In some cases" meant the case where the database had been made into ODS 11 by restoring a Fb 1.5 backup under the Fb 2.0 server. At best, it has been something to suggest in the support list when a user has screwed up a migration.

My recollection is that Claudio *did* attempt some improvement to gbak at that point (during Fb 2.0 betas) to make it so that the Fb 2.0 version of gbak could take a switch to specify "make a downgradeable backup". During the Fb 2 workup period I was pretty aggressive about getting developers to document new features and improvements. Dmitry also assembled a pretty comprehensive set of Migration topics, which was updated later for Fb 2.1. Claudio has also improved and updated the on-line help for gbak during these years. We're talking of a period encompassing five years here and this improvement/feature has not materialised in that time.

Thus, unless Claudio has something he is hiding from us, I think the situation did not change, up to and including the latest evolutions of Fb 2.x. That is, one should never go blindly into upgrading the ODS of a database if one is likely to need a fallback.

The Migration and Installation Guide for Fb 2.0 and 2.1 has a section for Special Issues. At the moment, it contains one article, regarding the MSVC8 runtimes issues on Windows. If we can get the facts straight regarding gbak and its mysteries, it might make some sense to include an article there on just what can and can't be done.

@firebird-automations
Copy link
Collaborator Author

Commented by: Claudio Valderrama C. (robocop)

As far as I understand, Dmitry changed the way security classes are handled in v2.5. This makes virtually impossible to downgrade to v2.1. There are other issues like the length of the context name for views that was changed from 2.0 to 2.1 and again from 2.1 to 2.5.
Before the security classes changes I had some success in downgrading databases.
:-)
I don't know how much is reasonable to complicate gbak to cather for the differences among server versions, considering that old server cannot understand new BLR and thus only data and non-procedural metadata can travel backwards safely. For example, I consider a computed column a case of procedural metadata.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

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