How the Installation Handles Schema Similarities

A simple name collision occurs when a framework administration object has the same name as a custom administration object in the database (i.e., an object that was never installed as part of the framework). In this case, the symbolic names of the objects are not the same: either the existing object has no symbolic name or its symbolic name is different from that of the framework object. When the framework setup program finds a name collision, it renames the administration object that it is installing using the format "eService<version-number>~<original-name>".

After the framework is installed, you can find any name collisions by examining the installation log file.

For example, suppose your database contains a Widget type and you are installing version 9.0.0.0 of the framework, which also contains a Widget type. When the framework installs, it renames its Widget type to "eService9000~Widget". It does not change the type's symbolic name.

When framework installation encounters an existing object with the same symbolic name as an object it is adding or modifying, it checks whether the MQL command for the object is an Add or Modify command. If an Add command, setup skips the command and logs the skip action in the log file. If a Modify command, setup checks the existing object's Application property to determine whether it is a FrameworkFuture object. How setup proceeds depends both on the value of this property and how the version number of the existing object compares to that of the installing object.

There are two types of values for the Application property:

• Framework or anything other than FrameworkFuture—The object was installed by the framework or is a custom object.
  
  • If the Version property on the existing object is less than that of the installing object (i.e., the existing object is older than the installing object), then setup modifies the object.
  • If the Version property on the existing object is equal to or higher than that of the installing object (i.e., the existing object is the same or newer than the installing object), then setup skips the Modify command.
  • If a new manifest file has been selected, then setup may modify the object.
• FrameworkFuture—This is a special case in which the schema is flagged as a future part of the framework. This only occurs when a customer works closely with ENOVIA Engineering to add a new schema. When a schema is flagged as FrameworkFuture, the Version property is also updated with the version number of the framework in which the new or modified schema will appear.
  
  • If the Version property on the existing object is less than that of the installing object (i.e., the existing object is older than the installing object), then setup executes the Modify command.
  • If the Version property on the existing object is the same as that of the installing object, then setup skips the Modify command and changes the Application property from FrameworkFuture to Framework to identify it as a framework object. It then logs a message to the log file to indicate that the object has been synced and the Modify command has been skipped.
  • If the Version property on the existing object is higher than that of the installing object (i.e., the existing object is newer than the installing object), then setup skips the Modify command and indicates the skipped command in the log file.
  • If a new manifest file has been selected, then the installation may modify the object.

The following table summarizes how the system handles symbolic name matches: