The CONNX Data Dictionary (CDD) is a repository of information describing the data tables and fields in the accessed databases, including security. The CDD contains the metadata about the source information and provides easy maintenance of the metadata, views, and integrated security.
This document provides an overview of the options available to users to configure and manage CDDs when they have multiple test and production configurations to support and they need to move updates from the test environment into production.
Identical database layouts #
If the user has test and production systems where the database layouts, and therefore the CDD structures, are identical then he can simply copy the test CDD to production and use the CONNX Data Dictionary Utility change the DBID at the high level. This will change the Adabas DBID for all the files defined for that database in this CDD.
If the test and production databases are not on the same server then the default server name has also to be updated to reflect the location of the production server.
The Adabas File Name in the file individual entries will still reflect the original DBID but will not be used when accessing the file. However, if required, the CONNX registry setting HONORDBIDFILEID can be used to override the high level DBID setting and force use of the DBID associated with the individual file entries.
When moving a CDD into production you may also want to consider applying stricter security options, for example by making the CDD read only, and reviewing any password setting. See below:
Different database layouts
If the test and production CDDs are not identical then users have the following methods of maintaining them:
Data Description Language (DDL)
CONNX provides an option to import metadata from scripts containing two of Software AG's specific SQL commands CREATE TABLE DESCRIPTION and CREATE CLUSTER DESCRIPTION.
The user can maintain the CDD via DDL statements which they can keep in a source control system. When they make changes to the Adabas database they also update the DDL and re-create the CDD.
The script containing the DDL statements can also be submitted in batch via the ACEINT utility.
Predict can create DDL statements from Adabas file definitions kept in the Predict repository. See the relevant Predict documentation on Adabas SQL Gateway for more details. The DDL can then be used to create a CDD as above.
The user can create and maintain separate CDDs for each application and the production CDD contains links to these individual CDDs.
The application teams can then update the individual CDD for that application and replace it in production as required.
Data Dictionary Comparison Utility
A very convenient way of ascertaining if there are differences between CDDs is to use the Data Dictionary comparison tool.
The “Get Differences” report shows differences at the database and table and view level.
Unfortunately there is currently no automatic method of applying differences identified to either of the CDDs. The changes have to be made manually via the CONNX Data Dictionary utility or the Replication Administrator utility.