Inserting a Schema into the Schema Hierarchy
You can use the jadclient executable to insert one schema into the schema hierarchy above another schema. This inserts (or moves) an existing schema that has no subschemas to a new position in the schema hierarchy, enabling you to create the new schema in the hierarchy and then use a standard schema load after the insertion processing has completed to deploy the required classes.
Although it is preferable to insert an "empty" schema (that is, one that contains only the
As a precaution, you should backup your database before inserting a schema and then perform a meta certify of your database after the changes are committed. For details, see "
To insert a schema into the schema hierarchy, specify the following arguments in the jadclient program.
jadclient path=database-path ini=jade-initialization-file schema=RootSchema app=JadeInsertSchema server=singleUser startAppParameters superschema=superschema-name subschema=subschema-name
To insert a schema into the schema hierarchy, you must run the executable in single user mode. The schema command line argument value must be RootSchema and the
jadclient path=c:\jade\system ini=c:\jade\system\jade.ini schema=RootSchema app=JadeInsertSchema server=singleUser startAppParameters superschema=TestSchema subschema=CommonSchema
A reorganization is required as part of the schema insertion process.
Before inserting TestSchema above CommonSchema, the schema hierarchy would be like that shown in the following image.
The JadeInsertSchema application reports progress and errors to the InsertSchema.log file in your Jade logs folder. This file contains details of any conflicts that prevent the schema being moved.
After running the JadeInsertSchema application, the schema hierarchy would look like that shown in the following image.
The following restrictions apply to the current release of this feature.
-
Neither the superschema nor the target schema can be versioned.
-
If the superschema being inserted has subschema copy classes, the classes must exist in the new hierarchy at which it is being inserted.
-
Where the superschema is not an "empty" schema, the following conflicts result in the operation being cancelled.
-
Class name conflicts
-
Constant category conflicts
-
Global constant conflicts
-
External function name conflicts
-
ActiveX library name conflicts
-
Database name conflicts
-
Delta id conflicts
-
Exported package name conflicts
-
Imported package name conflicts
-
External database name conflicts
-
Interface name conflicts
-
Method number conflicts (subschema copy class)
-
Library name conflicts
-
RPS database name conflicts
-
Relational view name conflicts
-
Schema view name conflicts
-
User format names conflicts
-
Translatable string name conflicts
-
Constant name conflicts (subschema copy class)
-
Method signature conflicts (subschema copy class)
-
Method name conflicts (subschema copy class)
-
A package used by the inserted superschema that is defined by one of the schemas that will become a subschema of this schema
-
A package defined in the superschema that is used by one of the schemas that will become a subschema of this schema
-