The CDD is a snapshot of the metadata at import time.  Over time, the CONNX tables structures will change.  This section describes several strategies you can use to manage table structure changes in a controlled fashion.

 

If your organization has discrete development, test, and production environments, maintain three separate data dictionaries for each environment.  This isolates each environment from each other; you can test any changes in one environment without affecting the others.  When it comes time to propagate changes from development CDD to test CDD, or from a test CDD to a production CDD, there are several techniques.

 

• If there are no changes to the metadata (exactly the same between the environments), the CDD file can be copied from one name to another.
  
  Note: This usually occurs when the database or server name changes, but nothing else has changed
  
  Use the CDD manager to change the name of the database and/or server by selected the red database cylinder and making the appropriate changes.  The exact metadata tested in one environment will be used in the next environment.  
  
  This option will require some downtime, as any connections to the CDD will need to be closed before a new copy can replace the old.  Shut down the JDBC Server and any client connections to the data dictionary.  This is typically done during a nighttime batch window or a planned weekend outage.
   

• If the metadata between the two environments are different enough that a CDD file copy will not work, use the data dictionary manager to re-import the changed tables.
  
  This will require some downtime, as any connections to the CDD (such as the JDBC Server or any client connections to the data dictionary) will need to be closed before a new copy can replace the old version. This is typically done during a nighttime batch window or a planned weekend outage.
   

• For some data adaptors, such as ADABAS, the metadata can be changed by using DDL SQL statements, such as Create Table Description or Create Table Cluster Description.  Using these DDL statements, old metadata definitions can be removed, and new definitions created.   Since the DDL statements can be issued using a variety of interfaces to CONNX (JDBC, ODBC, .NET, OLEDB), there is no downtime required for this type of metadata update.  The CDDs can be updated while online and in use, simply by using the required SQL statements.