Database upgrade

There are two possible levels of database upgrade. When internal structures as database header have been changed, a system upgrade becomes necessary. Changing metadata structures (resource type definitions), will cause a schema upgrade.

Upgrading databases is possible from previous version to next version, only, i.e. one cannot upgrade e.g. from version 11 to version 13. Instead, one has to upgrade first from version 11 to version 12 and than from 12 to 13.

In many cases, databases are upgraded automatically, which will be explained in release notes for new major versions. Minor versions do never require system or schema upgrades.

After upgrading a database to a new system or schema version, the database cannot be accessed with older schema or software versions.

Changes for system headers for databases or object spaces are, usually, upgraded automatically. Changing instance descriptors may be automatically upgraded, but sometimes, a database copy is required.

After upgrading a database to a new system version, the database cannot be accessed with older software versions. In order to allow accessing databases simultaneously with current and previous software version, one may suppress automatic system upgrade by setting the SYSTEM_UPGRADE option to NO (data source or application level). This, may however, disable additional features for new version.

When the ODABA schema version changes, resource databases and databases referring to ODABA system data types (typically __OBJECT or DSC_Topc), have to be upgraded. In many cases, online evolution is possible, which automatically upgrades database instances to the new schema version when being updated. In some cases, however, an explicit database upgrade becomes possible. Release notes for new major versions contain upgrade appropriate notes. The following paragraphs describe the upgrade procedure required for the latest version.

In order to upgrade a resource database (dictionary), the ode.sys database containing extended system resource definitions is required with old and new version. The installation contains an appropriate old version database (e.g.ode.sys_V21) extended by the old version number. The new system database is the ode.sys shipped with the installation.

Before starting the upgrade procedure (Upgrade.cmd as described below), it is suggested to create a copy of the old database (here we use the extension _old). When copying the database terminates successfully, one may replace your dictionary with the upgraded resource database. From the example below, one may simply create your upgrade procedure by replacing %DB% and storing the Upgrade.cmd and Upgrade.ini file.

In order to upgrade an application database, which is rarely necessary, nearly the same procedure might be used. Just the DICTIONARY has to be replaced by old and new resource database, as shown in the comment lines in the ini-file. In this case, %DB% refers to the application database to be upgraded while %RDB% refers to the resource database, which already had been upgraded.

Under Linux a script is provided that evaluates the current database version and upgrades it to a temporary directory:

    (/usr/local/share/odaba/upgrade /path/to/data.base)