BOI Software Entwicklung und Vertrieb GmbH

Phone: +43 (0) 732 / 736423 - 0

Spazgasse 4


4040 Linz, Austria

What has to be considered at a release update?


When upgrading to a new TABEX/4 release, when providing fixes and during configuration, questions about control tables arise.

See also BOI Wiki entry How are the control tables organized in TABEX/4?

The following sections describe the TABEX concept and approach of the control tables in various cases.


TABEX concept for upgrading control tables

In TABEX/4 a strict separation between customer control tables and system control tables is implemented.

With this concept the update to a new release is easy and secure for the customer. Configuration data in the customer control tables are not overruled by the contents of system control tables.

System control tables are only maintained by BOI and are always stored in BOI databases.

Customer control tables are chained with system control tables and are used first.

In the chained customer control databases the system control tables are only stored temporarily in case of an update or a correction of an error between releases.

When delivering a new release, customer control tables are also stored only in the BOI databases. They are either empty or only contain examples. The customer control table of the previous release (the customer control table chained with the system control table) remains unchanged. (Changes in the structure of customer control tables are updated using the job ADAPTCTL).

How to configure the control tables is described in the BOI Wiki entry Organization of the control tables.


Customer control tables can be maintained with the administrator menu item "edit control tables".

Some of the customer control tables can be maintained with specific administrator menu items.

Also functions of the Admin GUI change customer control tables.

After editing a customer control table with one of the methods listed above, this customer control table is stored in the chained customer control database.

When loading the control table by an application the customer control table is read at first.

If the customer control table is empty, the system control table from the BOI database is used.

So customer configurations always overrule system settings defined in the system control tables stored in the BOI database.

All control tables which have not the name schema of BOI are also identified as customer control tables.
These tables can be configured with the administrator menu item "edit control tables".

For the definition the administration menu items "add customer control tables" and "add customer control tab. text" can be used.

Release update

In a release update all BOI databases and thus all system control tables are exchanged.

Our recommendation is to use the customer control tables in the chained customer databases, so that the configuration of the previous release is remains and is not deleted.

Adjustments to the customer control tables, which sometimes are required at a release update, are largely automated by the batch job ADAPTCTL.

This method also allows to skip releases without a temporary installation of every interim release.

The batch job is described in the documentation of the release update procedure BOIDOC_250….

Sometimes additional manual adjustments are required. These are also described in the documentation of the release update procedure BOIDOC_250.

Note, when skipping releases: All manual adjustments of all interim releases must be executed!

Providing fixes and preliminary releases

Adjustments to the installed release, which are provided by BOI (e.g. provided as control tables and program tables), should always be initially loaded into the chained customer control tables of the customer database.

If the test of the adjustments in the customer environment are not successful, the adjustments can easily removed by deleting these tables from the chained customer control tables.

Note: After a successful test, the adjusted customer control tables must be moved from the customer control tables to the system control tables and must be deleted in the customer control database.

This step is necessary to avoid problems at the next release update:

If the adjusted system control tables  remain in the chained customer database, they are used instead of the BOI system control tables and may overrule new or changed BOI system control tables.

This can lead to various errors and is difficult to correct.

The functionality of preliminary releases and fixes that have been provided for a specific release is always included in the current development, and therefore automatically included in the next release.

If the customer's installed release is not the latest published release, then the adjustment will only be made for the current release (which is currently developed). Releases between the customer's installed release and the next release (which is currently developed) are NOT available, but will only take effect at the next release.

Exceptions: e.g. when a critical error is corrected, fixes for all the releases, which are in maintenance, are provided.


Changes in ESA data spaces, efficient migration and a new success story: Learn more in our newsletter!


Migration Packages

BOI GmbH offers migration packages for the table management systems SPITAB, TABSYS and VTAS.


» Migration Packages

Success Stories

GDIS and BOI: Carrying on the Success

With TABEX4 JTC, GDIS has introduced the world's fastest Java interface for table access on customer and control data. Learn the details in our new Success Story.


» read this Success Story

» read more Success Stories