MicroStrategy ONE

Resolve Conflicts when Copying Objects

In the MicroStrategy system, every object has an ID (or GUID) and a version. The version changes every time the object is updated; the ID is created when the object is created and remains constant for the life of the object. To see the ID and version of an object, right-click the object and select Properties.

When copying objects across projects with Object Manager, if an object with the same ID as the source object exists anywhere in the destination project, a conflict occurs and the Conflict Resolution dialog box (shown below) opens. It prompts you to resolve the conflict.

The table below lists the different kinds of conflict:

Conflict

Explanation

Exists identically

The object ID, object version, and path are the same in the source and destination projects.

Exists differently

The object ID is the same in the source and destination projects, but the object versions are different. The path may be the same or different.

Exists identically except for path

The object ID and object version are the same in the source and destination projects, but the paths are different. This occurs when one of the objects exists in a different folder.

If your language preferences for the source and destination projects are different, objects that are identical between the projects may be reported as Exists Identically Except For Path. This occurs because when different languages are used for the path names, Object Manager treats them as different paths. To resolve this, set your language preferences for the projects to the same language.

If you resolve the conflict with the Replace action, the destination object is updated to reflect the path of the source object.

Exists identically except for Distribution Services objects

(User only) The object ID and object version of the user are the same in the source and destination projects, but at least one associated Distribution Services contact or contact group is different. This may occur if you modified a contact or contact group linked to this user in the source project.

If you resolve the conflict with the Replace action, the destination user is updated to reflect the contacts and contact groups of the source user.

Does not exist

The object exists in the source project but not in the destination project.

If you clear the Show new objects that exist only in the source check box in the Migration category of the Object Manager Preferences dialog box, objects that do not exist in the destination project are copied automatically with no need for conflict resolution.

Choosing an Action to Resolve a Conflict

If a conflict occurs you must determine what action Object Manager should take. The different actions are explained in the table below.

When Object Manager reports a conflict it also suggests a default action to take for that conflict. For information on changing the default action, see Setting Default Actions for Conflict Resolutions.

User Action

Effect

Use existing

No change is made to the destination object. The source object is not copied.

Replace

The destination object is replaced with the source object.

If the conflict type is Exists Identically Except For Path, or Exists Identically Except For Distribution Services Objects, the destination object is updated to reflect the path or Distribution Services addresses and contacts of the source object.

Replace moves the object into same parent folder as the source object. If the parent path is the same between source and destination but the grandparent path is different, Replace may appear to do nothing because Replace puts the object into the same parent path.

Non-empty folders in the destination location will never have the same version ID and modification time as the source, because the folder is copied first and the objects are added to it, thus changing the version ID and modification times during the copy process.

Keep both

No change is made to the destination object. The source object is duplicated in the destination location.

Use newer

If the source object's modification time is more recent than the destination object's, the Replace action is used.

Otherwise, the Use existing action is used.

Use older

If the source object's modification time is more recent than the destination object's, the Use existing action is used.

Otherwise, the Replace action is used.

Merge (user/group only)

The privileges, security roles, groups, and Distribution Services addresses and contacts of the source user or group are added to those of the destination user or group.

Do not move (table only)

The selected table is not created in the destination project. This option is only available if the Allow to override table creation for non-lookup tables that exist only at source project check box in the Migration category of the Object Manager Preferences dialog box is selected.

Force replace (Update packages only)

Replace the object in the destination project with the version of the object in the update package, even if both versions of the object have the same Version ID.

Delete (Update packages only)

Delete the object from the destination project. The version of the object in the update package is not imported into the destination project.

If the object in the destination has any used-by dependencies when you import the update package, the import will fail.

Warehouse and other database tables associated with the objects moved are handled in specific ways, depending on your conflict resolution choices. For details, see Conflict Resolution and Tables.

If you choose to replace a schema object, the following message may appear:

The schema has been modified. In order for the changes to take effect, you must update the schema.

This message also appears if you choose to replace an application object that depends on an attribute, and you have made changes to that attribute by modifying its form properties at the report level or its column definition through another attribute. For information about modifying the properties of an attribute, see the Project Design Help.

To update the project schema, from the Object Manager Project menu, select Update Schema. For details about updating the project schema, see the Optimizing and Maintaining your Project section in the Project Design Help.

To Resolve a Conflict

  1. Select the object or objects that you want to resolve the conflict for. You can select multiple objects by holding down SHIFT or CTRL when selecting.
  2. Choose an option from the Action drop-down list (see table above).
  3. On the toolbar, click Proceed.

Setting Default Actions for Conflict Resolutions

You can determine the default actions that display in the Conflict Resolution dialog box when a conflict occurs. This includes setting the default actions for the following object categories and types:

  • Application objects
  • Schema objects
  • Configuration objects
  • Folders
  • Users and user groups

For a list of application, configuration, and schema objects, see Copy Objects. For an explanation of each object action, see Choosing an Action to Resolve a Conflict.

You can set a different default action for objects specifically selected by the user, and for objects that are included because they are dependents of selected objects. For example, you can set selected application objects to default to Use newer to ensure that you always have the most recent version of any metrics and reports. You can set dependent schema objects to default to Replace to use the source project's version of attributes, facts, and hierarchies.

These selections are only the default actions. You can always change the conflict resolution action for a given object when you copy that object.

To Set the Default Conflict Resolution Actions

  1. From the Tools menu, select Object Manager Preferences.
  2. Expand the Conflict Resolution category, and select Default Object Actions.
  3. Make any changes to the default actions for each category of objects.
  4. Click OK.

Conflict Resolution and Access Control Lists

When you update or add an object in the destination project, by default the object keeps its access control list (ACL) from the source project. You can change this behavior in two ways:

  • If you resolve a conflict with the Replace action, and the access control lists (ACL) of the objects are different between the two projects, you can choose whether to keep the existing ACL in the destination project or replace it with the ACL from the source project.
  • If you add a new object to the destination project with the Create New or Keep Both action, you can choose to have the object inherit its ACL from the destination folder instead of keeping its own ACL. This is helpful when copying an object into a user's profile folder, so that the user can have full control over the object.

The Use Older or Use Newer actions always keep the ACL of whichever object (source or destination) is used.

To Set the ACL Options

  1. From the Tools menu, select Object Manager Preferences.
  2. Expand the Conflict Resolution category, and select Access Control List.
  3. Under ACL option on replacing objects, select how to handle the ACL for conflicts resolved with the Replace action:
    • To use the ACL of the source object, select Keep existing ACL when replacing objects.
    • To use the ACL of the replaced destination object, select Replace existing ACL when replacing objects.

    If this option is selected, the ACL is replaced even if the source and destination objects are identical.

  4. Under ACL option on new objects, select how to handle the ACL for new objects added to the destination project:
    • To use the ACL of the source object, select Keep ACL as in the source objects.
    • To inherit the ACL from the destination folder, select Inherit ACL from the destination folder.
  5. Click OK.

Conflict Resolution and Tables

When an attribute or fact is migrated from one project to another using Object Manager, either specifically or because it is a dependent of another object, by default all dependent tables are also migrated. This includes warehouse tables as well as MDX tables and XDA tables.

You can choose not to create a dependent table in the destination project by changing the Action for the table from Create New to Ignore. You can also choose not to migrate any dependent tables by specifying that they not be included in Object Manager's dependency search. For detailed information, including instructions, see What happens when You Copy or Move an Object.

The following list and related tables explain how the attribute - table or fact - table relationship is handled, based on the existing objects and tables and the conflict resolution action you select.

In the following list and tables, attribute, fact, and table descriptions refer to the destination project. For example, "new attribute" means the attribute is new to the destination project: it exists in the source project but not the destination project.

  • New attribute or fact, new table: There is no conflict resolution. By default the table is moved with the object. You can choose not to create the dependent table in the destination project by changing the Action for the table from Create New to Ignore.
  • New attribute or fact, existing table: The object in the source project contains a reference to the table in its definition. The table in the destination project has no reference to the object because the object is not present in the destination project. In this case the new object will have the same references to the table as it did in the source project.
  • Existing attribute or fact, new table: The object in the destination project does not refer to the table because the table does not exist in the destination project. The object in the source project contains a reference to the table in its definition.

    Object Action

    What happens in the destination project

    Use Existing

    The object does not reference the table.

    Replace

    The object has the same references to the table as it does in the source project.

    Keep Both

    No change is made to the destination object. The source object is duplicated in the destination project. The duplicated object will have the same references to the table as it does in the source project.

  • Existing attribute or fact, existing table: The object has a reference to the table in the source project but has no reference to it in the destinatio project.

    Object Action

    What happens in the destination project

    Use Existing

    The object does not reference the table.

    Replace

    The object has the same references to the table as it does in the source project.

    Keep Both

    No change is made to the destination object. The source object is duplicated in the destination project. The duplicated object will have the same references to the table as it does in the source project.

  • Existing attribute or fact, existing table: The object has no reference to the table in the source project but has a reference to it in the destination project.

    Object Action

    What happens in the destination project

    Use Existing

    The object has the same references to the table as it did before the action.

    Replace

    The object does not reference the table.

    Keep Both

    No change is made to the destination object. The source object is duplicated in the destination project. The duplicated object will not reference the table.