Library

gstat –h database_file_name

Wrong ODS version, expected 8, encountered 32779?

can't format message 21:3 -- message file ...msg not found

unsupported on-disk structure for file ...; found 32779, support 10

Sometimes server may upgrade old ODS to some newer one, without notification. This can lead to the impossibility of returning to the version back. For example, if you open a database with ODS 8.0 with InterBase 4.2, it will upgrade ODS to 8.2, which is not understandable by InterBase 4.0/4.1. So, the minor upgrade of ODS makes incompatible databases within same major server version. This is also true for Firebird 2.5 and InterBase 7.5.

To avoid problems of returning to version back we recommend doing backups on current server version even before the minor upgrade of your server version.

The difference between ODS (major or minor) can be huge, or small. If you are curious enough, you can open jrd\ods.h (Firebird open source) and find differences between ODS. For example, ODS 9.0 compared to 8.x has declarative referential integrity, SQL roles, garbage collection in indices. But ODS 9.1 differs from 9.0 only by one index, added to some system table.

Note, that major ODS version can’t be upgraded on the fly. You can upgrade it only by backup/restore.

Migration between InterBase and Firebird

Last versions of Firebird (3.0) and InterBase (XE7) are very different, by features and ODS. As it was said before, the last common was ODS 10, and since then (Firebird 2.0 and InterBase 7.0) databases are incompatible with its format.

So, migration will be easier if you have not used features since InterBase 7.x or Firebird 1.5. If yes – the complexity of the migration will depend on how many features you used in the database or administration process.

Currently, after many years of Firebird and InterBase development, migration between the latest versions of these servers is difficult.

Anyway, if you try to do this, you need to extract metadata script from the database, and then try to create the new database from that script, using the same server.

isql -x db.gdb …
isql -i script.ddl …

This need to be done to check if there any bad old metadata in your database or bugs of script extraction in the server you use. InterBase and Firebird store procedures, triggers and views (and some other objects) in compiled form (BLR – Binary Language Representation), and during backup/restore metadata are not being recompiled (from SQL to BLR).

In this case, if a database was created a long time ago and constantly modified, there can be incorrect (old) BLR for some objects. These objects can still work, but trying to recreate them (ALTER) can raise syntax (or another) error.

Then you can try to create a database from corrected script at the new server. After you fix all incompatibilities in this script, you can pump data from the old database to the new database.

Even if you tried to backup on the old server and restore at new, and it worked – never trust this. If your database contains a lot of objects, you can’t check all of them at once on the new server, so, the error will raise some time later.

How to return to the previous version of Firebird or InterBase

Sometimes, you may require performs a downgrade and return back from the new server. Reasons may vary – sudden bug in the server, performance issues, and so on.

If you made the backup before server upgrade, there will be no problems to return back. But if not, you will face the problem of returning from the new ODS to old ODS.

To do that you will need 2 computers with the new server and the old one. If you haven't used any new features of server X (version of InterBase or Firebird), so you may return to X-1 following these steps:

1. Take gbak utility from the server X-1, and make backup using it at server X
2. Transfer backup to the X-1 server, and restore it

If there are some problems at the 1 step, you may try

1. Make backup at server X, using its gbak
2. Copy gbak utility from X to X-1
3. Restore backup at X-1 using gbak from X

Note, that local protocol between servers X and X-1 can be incompatible, so, it’s better to specify server name:

gbak –b localhost:c:\dir\data.gdb 

The result will be successful only with the condition, that you haven’t changed any of the database objects at server X since you upgraded from X-1.

Here are examples:

• From 5.x to 4.2 - none roles and new declarative referential integrity must be used
• From 6.x to 5.x – none metadata changes, because 6.x use new BLR format
• From InterBase 7.x to Firebird – none boolean columns and object names longer 31 characters.
• From Firebird 1.5 to InterBase – no BIGINT columns and new SQL extensions in triggers and procedures
• From Firebird 2.0 to Firebird 1.5 – none of new Firebird 2.0 functionality.
• And so on

If there are still errors, that cannot be fixed, the only way is to create the database at X-1 server from the SQL script and pump data.
 

Firebird Migration service

Often the migration the complex task, especially for legacy Firebird databases, which were abandoned by original developers. Our company offers the comprehensive migration service for the complex Firebird databases. The regular fee is USD$2900. 
For example, we have migrated the database which SQL script was 55 Megabytes, with more than 5000 stored procedures, 1000 tables and several thousands of ad hoc SQL queries, in less than 3 months.

If you have any questions, please contact us [email protected]