| Subject | Re: [firebird-support] Re: Rolling back from 2.5 to 2.0 |
|---|---|
| Author | Helen Borrie |
| Post date | 2013-01-08T23:00:37Z |
At 11:07 a.m. 9/01/2013, Alexandre Benson Smith wrote:
The API (application programming interface, the layer that applications use to communicate with databases through the server) is also likely to undergo changes in a major version upgrade. This will affect how user applications access data, in ways that would be hard to guess without some meaningful symptoms. For that reason, performing a major server upgrade is a bad idea unless you are in control of what the application can do to work with the API changes.
You might be getting permission/privilege problems, if you lost the security database in the process of installing the new version. That problem is relatively easy to fix if you still have the security database (security2.fdb) that shipped with your application package.
You haven't given enough information for anyone to tell whether your troubles are coming from ODS changes, API changes, or both. There are expert's techniques that can sometimes work to "downgrade" a database to an older ODS. If you have gotten yourself in the position of having wrecked a production database without any backups you can restore and revert to, you would be best advised to get professional help. Whatever you do, hang on to any backups and take a file copy of the database in its current state.
Alternatively, the vendor of your application software may have tools to deal with this kind of mess. It's worth trying.
./heLen
> > Could it be the ODS upgrade ?At 11:19 a.m. 9/01/2013, halaekinree wrote:
>Good thought, but the database structure is still the same - the only thing that changed is the server version.You missed the point of Alexandre's question. The on-disk structure (ODS) of a database is upgraded when you restore under a newer server a database with an older ODS than what the newer server creates. The actual *data structures* of the user data are not changed by this, although the structures of the metadata usually are. That's why databases are not backward-compatible and one strong reason not to commit a production database to such a change without thorough lab work.
>
>Thanks for the suggestion though!
The API (application programming interface, the layer that applications use to communicate with databases through the server) is also likely to undergo changes in a major version upgrade. This will affect how user applications access data, in ways that would be hard to guess without some meaningful symptoms. For that reason, performing a major server upgrade is a bad idea unless you are in control of what the application can do to work with the API changes.
You might be getting permission/privilege problems, if you lost the security database in the process of installing the new version. That problem is relatively easy to fix if you still have the security database (security2.fdb) that shipped with your application package.
You haven't given enough information for anyone to tell whether your troubles are coming from ODS changes, API changes, or both. There are expert's techniques that can sometimes work to "downgrade" a database to an older ODS. If you have gotten yourself in the position of having wrecked a production database without any backups you can restore and revert to, you would be best advised to get professional help. Whatever you do, hang on to any backups and take a file copy of the database in its current state.
Alternatively, the vendor of your application software may have tools to deal with this kind of mess. It's worth trying.
./heLen