If you don’t impose a site-specific naming convention for Workspace items (queries, reports, charts, and so on), users and groups, and other stateless records, it is possible to have different objects with the same name.
For example, duplicate names can occur when user administrators at two sites within a clan add the same user name within a synchronization cycle. In this case, after the replicas are synchronized, two users have the same name.
Internally, ClearQuest ensures that records and Workspace names are unique:
If two Workspace items (queries, reports, and so on) have the same name, both items work as expected in the Windows and UNIX clients, according to mastership restrictions and database privileges. However, in ClearQuest Web, only one of the items works. To avoid confusion, you must rename one or both of the items.
In order for you to modify a Workspace item, your current replica must master it. To determine which replica masters a Workspace item, open the Workspace, right-click the item, and click Mastership.
To rename a Workspace item:
If you need to use multiutil commands to work with a Workspace item with a naming conflict, you must refer to its keysite name, which is the name of the site where the Workspace item originated. For example:
The following example uses the keysite name in the object selector:
multiutil describe -clan telecomm -site tokyo -family PRODA -user tokyoadmin -password secret "workspace:Public Folder\Project Report<boston_hub>" Multiutil: Mastership of ‘workspace:Public Queries\Project report<boston_hub>’ is ‘boston_hub’.
To fix a naming conflict for a stateless record, you must rename one of the records.
To rename a stateless record that has a naming conflict:
To rename a stateless record, you must modify a field that is used as the unique key for that record. To do this, use the action in your schema that allows you to modify records without changing their state.
To ensure that a record is unique, stateless record types use the ratl_keysite field. The ratl_keysite field is an internal system field that stores the name of the site where an object was created.
For example, a new customer named NetInc is created at two replicas during the same time period between synchronizations. When each replica synchronizes, there appear to be two customer records with identical names. To ensure uniqueness, ClearQuest references the ratl_keysite field.
If you need to use describe or chmaster commands to work with an ambiguous record, you must refer to its keysite name (originating site name). For example:
The following example uses the keysite name in the object selector:
multiutil describe -clan telecomm -site tokyo -family PRODA -user masako -password secret customer:NetInc<boston_hub>
Multiutil: Mastership of ‘customer:NetInc<boston_hub>’ is ‘boston_hub’.
You can use the ratl_keysite field in queries designed to find stateless records of the same name. Follow these guidelines when querying for stateless records with naming conflicts.
To assist you in viewing and modifying records, you can add the ratl_keysite field to the form of any stateless record type where you expect naming conflicts to arise. For more information, see the Administrator’s Guide for Rational ClearQuest.
To log on with an ambiguous user name, use the keysite name as part of the user logon name (for example, username<keysite-name>, where keysite-name is the site where the user was created). If you log on with an ambiguous user name without the keysite name, you get an invalid logon error. Clicking the detail displays the following error:
In ClearQuest Designer, when you try to modify user information for a user who has a conflicting name, you get the following error message because of the < > characters in the name:
ERROR! The string value ("DupUser<SITE1>") is invalid: Names cannot contain one of these characters:! "#$%&’()*+,./:;<=>?@[\]^‘{|}~
You must rename the user. You cannot modify any user information, except the Name field, until the user has a unique name that does not include the < > characters.
You cannot rename or delete a user group.
To rename a user:
If you need to use describe or chmaster commands to work with a user or group whose name is the same as another user or group, you must refer to their respective keysite name (originating site name).
Use the describe command to find out where the user is mastered. In this example, the keysite is the boston_hub replica: