Automatic update of database dictionary records

Service Manager can detect changes you make to existing columns and data types in your back-end RDBMS and then automatically update the database dictionary to match these changes after a system restart. This mechanism allows the database dictionary to better match the actual columns within the RDBMS. To trigger the automatic update of database dictionary records, you must first restart Service Manager and then make a query to the changed table in the RDBMS. Since several queries are made as part of the log in process, simply logging in may be sufficient to trigger an automatic update. For tables not queried during login, you will need to directly query the changed table in some fashion. You can either search from a form that queries the table or create a query from the Database Manager.

For example, suppose an RDBMS administrator changes the length of the "NUMBER" column in the "PROBSUMMARYM1" table from VARCHAR2(90) to VARCHAR2(100). To pick up the change, the administrator restarts the Service Manager server, logs in, and opens the incident queue form to trigger a query against the probsummary table. This process causes Service Manager to compare the database dictionary record to the RDBMS column definition, recognize the change, and update the database dictionary record to match. Service Manager writes all such changes to the log file. For example:

5120( 5872) 02/05/2009 10:57:00 RTE I Change of SQL data type for field 'number' from 'VARCHAR2(90)'
to 'VARCHAR2(100)' detected has been saved to DBDICT for file 'probsummary'

Note:  Service Manager can only change existing entries in database dictionary records, which are stored in the dbdict table. If your RDBMS administrator adds new columns intended for Service Manager to the RDBMS, the Service Manager administrator will have to manually add entries to the database dictionary to reflect those changes. If your RDBMS administrator removes columns managed by Service Manager, then Service Manager updates the database dictionary to map the file to a null table.

Note: In the above example, the "number" field is the unique key of the "probsummary" database dictionary, which maps to multiple tables in the out-of-box system. In an Oracle back-end RDBMS for example, the "probsummary" database dictionary maps to the "probsummarym1" and "probsummarya1" RDBMS tables. If you change the SQL data type of a unique key that is shared across multiple tables, be sure to make the same change in all associated tables. In our example above, the RDBMS administrator should also change the "number" column of the "probsummary a 1" table from VARCHAR2(90) to VARCHAR2(100). The Service Manager server displays a warning in the log file when it detects a difference between unique key definitions. For example:

4784( 4452) 02/05/2009 10:58:34 RTE W getSqldas: SQL data type for column 'NUMBER' in alias table a1
(VARCHAR2(90)) does not match SQL data type in main table (VARCHAR2(100))

Related topics

Automatic update of RDBMS data when database dictionary records change