What happens when You Copy or Move an Object

If the object you are copying does not exist in the destination project, MicroStrategy Object Manager copies the object into the destination project. This new object has the same name as the source object.

If the object you are copying does exist in the destination project, a conflict occurs and Object Manager opens the Conflict Resolution dialog box. For information about how to resolve conflicts, see Resolve Conflicts when Copying Objects.

Managing Object Dependencies

When an object uses another object in its definition, the objects are said to depend on one another. Object Manager recognizes two types of object dependencies: used dependencies and used-by dependencies.

When you migrate an object to another project, by default any objects used by that object in its definition (its used dependencies) are also migrated. You can exclude certain objects and tables from the dependency check and migration. For instructions, see Excluding Dependent Attributes or Tables from Object Migration.

Used Dependencies

A used dependency occurs when an object uses other objects in its definition. For example, in the MicroStrategy Tutorial project, the metric named Revenue uses the base formula named Revenue in its definition. The Revenue metric is said to have a used dependency on the Revenue base formula. (Additionally, the Revenue base formula has a used-by dependency of the Revenue metric.)

When you migrate an object to another project, any objects used by that object in its definition (its used dependencies) are also migrated. The order of these dependent relationships is maintained.

To Manage Used or Used-By Dependencies of an Object

After you have opened a project source and a project using Object Manager, in the Folder List select the object.
From the Tools menu, select Object used dependencies. The Used dependencies dialog box opens and displays a list of objects that the selected object uses in its definition. The image below shows the used dependencies of the Revenue metric in the MicroStrategy Tutorial project: in this case, the used dependency is the Revenue base formula.
In the Used dependencies dialog box, you can do any the following:
- View used dependencies for any object in the list by selecting the object and clicking the Object used dependencies toolbar icon.
- Open the Used-by dependencies dialog box for any object in the list by selecting the object and clicking the Object used-by dependencies icon on the toolbar. For information about used-by dependencies, see Used-By Dependencies.
- View the properties of any object, such as its ID, version number, and access control lists, by selecting the object and from the File menu choosing Properties.

Used-By Dependencies

A used-by dependency occurs when an object is used as part of the definition of other objects. For example, in the MicroStrategy Tutorial project, the Revenue metric has used-by dependencies of many reports and even other metrics. The Revenue metric is said to be used by these other objects.

Used-by dependents are not automatically migrated with their used objects. However, you cannot delete an object that has used-by dependencies without first deleting its used objects.

To Manage the Used-By Dependencies of an Object

After you have opened a project source and a project using Object Manager, from the Folder List select the object.
From the Tools menu, choose Object used-by dependencies. The Used-by dependencies dialog box opens and displays a list of objects that depend on the selected object for part of their definition. The image below shows some of the used-by dependencies for the Revenue metric in the MicroStrategy Tutorial project.
In the Used-by dependencies dialog box, you can do any of the following:
- View used-by dependencies for any object in the list by selecting the object and clicking the Object used-by dependencies icon on the toolbar.
- Open the Used dependencies dialog box for any object in the list by selecting the object and clicking the Object used dependencies icon on the toolbar. For information about used dependencies, see Used Dependencies.
- View the properties of any object, such as its ID, version number, and access control lists, by selecting the object and from the File menu choosing Properties.

Migrating Dependent Objects

When you copy an object using Object Manager, it checks for any used dependents of that object and copies them as well. These dependent objects are copied to the same path as in the source project. If this path does not already exist in the destination project, Object Manager creates the path.

For example, a user copies a report from the source project to the destination project. In the source project, all dependents of the report are stored in the Public Objects\Report Dependents folder. Object Manager looks in the destination project's Public Objects folder for a subfolder named Report Dependents (the same path as in the source project). If the folder exists, the dependent objects are saved in that folder. If the destination project does not have a folder in Public Objects with the name User, Object Manager creates it and saves all dependent objects there.

When you create an update package, click Add All Used Dependencies to make sure all used dependencies are included in the package. If the dependent objects for a specific object do not exist in either the destination project source or in the update package, the update package cannot be applied. If you choose not to add dependent objects to the package, make sure that all dependent objects are included in the destination project source.

Object Dependencies

Some objects have dependencies that are not immediately obvious. These are listed below:

Folders have a used dependency on each object in the folder. If you copy a folder using Object Manager, all the objects in that folder are also copied.
A folder that is copied as part of an update package does not have a used dependency on its contents.
Shortcut objects have a used dependency on the object they are a shortcut to. If you copy a shortcut using Object Manager, the object it is a shortcut to is also copied.
Security filters, users, and user groups have a used dependency on the user groups they belong to. If you copy a security filter, user, or user group, the groups that it belongs to are also copied.
Groups have a used-by dependency on the users and security filters that are associated with them. Copying a group does not automatically copy the users or security filters that belong to that group. To copy the users or security filters in a group, select the users from a list of that group's used-by dependents and then copy them.
Attributes used in fact expressions are listed as dependents of the fact. When the fact is copied, the attribute is also copied.
Attributes used in fact entry levels are not dependents of the fact.

Excluding Dependent Attributes or Tables from Object Migration

When you copy an object, or add dependent objects to an update package, Object Manager searches for that object's used dependencies so it can copy those objects also. Depending on the options you set in the Object Manager Preferences, you can exclude certain types of dependent objects from this migration.

The options are:

Exclude all parent attributes from an attribute and Exclude all child attributes from an attribute: An attribute has a used dependency on its parent and child attributes in a hierarchy. Thus, migrating an attribute may result in migrating its entire hierarchy. To exclude the parent or child attributes from being migrated, select the corresponding option.
Exclude non-lookup tables from an attribute and Exclude all tables from a fact: An attribute or fact has a used dependency on each table that is referenced by the attribute or fact. Thus, by default, migrating an attribute or fact results in migrating all its associated tables. You can choose to exclude the tables from the dependency search if, for example, you have mapped additional tables to an attribute or fact for testing purposes but do not need those tables in the production project.
For attributes, the lookup table must always exist in the destination project, so it is always migrated.

To Exclude Types of Dependent Objects

From the Tools menu, select Object Manager Preferences.
Expand Dependency search, and then select Dependency search.
Select the check boxes for the objects you want to exclude from Object Manager's dependency checking.
Click OK.

Timestamps for Migrated Objects

By default, when an object is migrated, the object's modification timestamp is updated to the destination Intelligence Server's migration process time. You can change this behavior so that the timestamp remains as the last modification time the object had in the source project.

To Set the Migrated Object Modification Timestamp

From the Tools menu, select Object Manager Preferences.
Expand Migration, and then select Migration.
To cause objects to keep the modification timestamp from the source project, select the Preserve object modification timestamp during migration check box. If this check box is cleared, objects take the modification timestamp from the destination Intelligence Server at the time of migration.
Click OK.

Copying Objects Between Projects in Different Languages

Object Manager's internationalization options allow you to specify the locale settings to be used when copying objects. You can also retain the object's name, description, and long description from the destination project, when replacing objects in the destination project using Object Manager.

The ability to retain the name, description, and long description is important in internationalized environments. When replacing the objects to resolve conflicts, retaining these properties of the objects in the destination project facilitates support of internationalized environments. For example, if the destination project contains objects with French names but the source project has been developed in English (including English names), you can retain the French names and descriptions for objects in the destination project. Alternately, you can update the project with the English names and not change the object itself.

To Set the Internationalization Options

From the Tools menu, select Object Manager Preferences.
Expand the International category, and select Language.
From the Interface Language drop-down list, select the language to be used in Object Manager. By default this is the language used in all MicroStrategy products installed on this system.
From the Language for metadata and warehouse data if user and project level preferences are set to default drop-down list, select whether copied objects use the locale settings from Developer or from the machine's regional settings.
For more information on metadata and warehouse data languages, see About Internationalization. For a table on the prioritization of user- and project-level language preferences, see Configuring Metadata Object and Report Data Language Preferences.
In the International category, select Translation.
To resolve translations with a different action than that specified for the object associated with the translation, select the Enable advanced conflict resolution check box.
- To always use the translations in the destination project, select Keep Existing.
- To always use the translations in the source project, select Replace.
Select the Merge translations even if object exists identically check box to update the translations for all copied objects in the destination project, according to the option specified above (Keep Existing or Replace (Default)), even if the object exists identically in both projects.
Click OK.