Modifying Non-SQL Defined Databases › Changes to Schemas and Subschemas

Changes to Schemas and Subschemas

In general, when you change a database, you must modify the schema code and revalidate the schema. However, changing the schema has an impact on other components of the CA IDMS/DB environment. If you add or delete an area from a schema, you may have to add or delete that area in one or more segments and regenerate DMCLs. You will also have to modify and recompile some or all subschema definitions compiled under the original schema to reflect changes made to the schema.

If you access the non-SQL defined data through SQL, you may also need to recompile access modules and drop and recreate SQL view definitions.

The primary tool for changing a schema is the schema compiler.

Steps to Modify the Schema

The steps to make any schema modification are as follows:

1. Change and re-validate the necessary schema and subschema definitions
2. Change the actual data (if it exists) to fit the new database specifications using the RESTRUCTURE, MAINTAIN INDEX, REORG or UNLOAD/RELOAD utility statements
3. Revise and recompile any application programs that may have been affected by the above changes
4. Test to ensure that the change has been made correctly.

Changes to Subschemas

Subschemas identify selected areas, records, elements, and sets of the database. They also define logical records and establish security by restricting runtime access to the database.

Any time you make a change to any of the above components in your CA IDMS/DB environment, you will have to change one or more of your subschemas.

The primary tool for changing subschemas is the subschema compiler.