Example of resolving duplicate names

If semantic type libraries are not managed centrally, you may encounter conflicts if you try to resolve custom types at a later time. The following example shows a method of resolving these conflicts.

In this example, custom semantic types are set up and assigned in three databases:

Databases with independant semantic types

You update the central Semantic Type Library by loading the custom semantic types from Databases A and B. The Trade Show and Motor Home semantic types are unique and are therefore loaded without any problems but the name Football Match already exists in the central Semantic Type Library, and loading the MTC file creates a custom semantic type with a duplicate name (Football Match_001) this can be deleted.

You then save an MTC file in order to distribute the new custom semantic types to the other databases. However, before loading it into Database A, you should delete the Football Match semantic type in Database A. After loading the MTC file, there will be no semantic types with duplicate names.

If the following situation occurs on loading the MTC file into Database A:

Databases

You need to remove the real duplicate in Database A. To do this, unassign and then delete Football Match, and then rename Football Match_001 to Football Match and reassign it.

Note: Loading the MTC file from the central Semantic Type Library into Database A, created a custom semantic type with a duplicate name. It is important to understand that in Database A, the real 'duplicate' is Football Match and that the one from the central Semantic Type Library was renamed on loading (Football Match_001).