Troubleshooting Multiuser Development

These are some common problems and how to resolve them in this section.

Orphan Lock Held on Master RPD

If a user sets a lock by issuing the command to publish changes to the network, it is not cleared until publishing is complete. If the user forgets and leaves for a two-week vacation, the MUD administrator can release the lock.

The lock is stored in a hidden system file in the master directory. If you cannot see the lock file, in Windows Explorer, select Tools, then select Folder Options. In the View menu, ensure that the option Show hidden files and folders is selected.

The lock file has the same name of the master RPD with a .lck extension. Delete the lock file to release the lock on the repository.

The image shows a repository lock file.

Description of the illustration GUID-3D33BEA1-A1BC-459C-9067-EFBD20CB69C1-default.png

Object Deleted By Other User

If another MUD developer deletes an object that you need, you can choose one of the following options:

• Roll back to an earlier version, and reapply all the changes since then. The easiest way to roll back is generally to replay history in the history log. To do this, choose File > Multiuser > History, and then select an entry and use Actions > View.

  See Viewing and Deleting History for Multiuser Development.

• Re-create the deleted objects, and equalize so that future merges treat it as the same object.

Project Missing Needed Physical Tables and Joins After Checkout

Physical objects do not explicitly belong to a project. Instead, the physical objects mapped to the logical fact tables in your project are extracted at the time of check out.

To get needed physical objects into your local extract, check out an additional project that does have mappings to the physical objects you need. If there is no such project, then the entire repository must be edited to create mappings to a logical fact table in your project. The MUD administrator can take the repository off line to make that change. Then, your next check out should include the physical objects.

Objects Added in the Last Session Missing from Checked Out Repository

If recently added objects are missing from your checked out repository, you might have forgotten to add the objects to your project before you merged and published. Only objects in your project, or inferred from your project like dimensions and physical objects, are included in your extracted repository.

To resolve this issue, ask the MUD administrator to add the objects to your project in the master repository, and then check out again.

Object Renamed by Appending #1

This situation occurs when two objects are merged with the same fully qualified name, but with different internal upgrade IDs. The merge logic in this situation determines that the objects are semantically different objects, and changes the name of the object to preserve uniqueness.

To resolve this issue, run the equalizerpds utility, which reassigns upgrade IDs so that objects with the same fully qualified names in the two repositories have the same upgrade IDs. Then, try the merge again. The two objects should be merged instead of causing a rename.

See Equalizing Objects.

Rolling Back to Previous Versions

The multiuser development environment stores backup copies of RPDs at appropriate checkpoints. Each time a potentially destructive operation is performed, a new backup is stored in the master directory. It has the name of the RPD, and the extension is a three-digit incrementing integer. Individual developers can also make copies of their RPD files at any time during development.

In the developer's sandbox, the original version of a checked-out project is stored with the name originalrpd_name.rpd. This version is automatically used if the developer discards changes.

You can also view and roll back to an older version by following these steps:

1. Open the Oracle BI Server, but not a repository.

2. Select File > Multiuser > History.

3. Select the version of interest, and then choose Actions > View > Repository.

4. Select File, then select Copy As to save that version to a new name.

5. Use the older version to replace the latest version, or replace the master repository with the older version.

Manually Updating the Master MUD Repository

During the course of Oracle BI repository development in a Multiuser Development (MUD) environment, it might be necessary to make manual changes to the master repository. Because of the highly controlled nature of the MUD process, you need to be careful when performing any manual steps because there is accounting information stored in the MUD history log (.mhl) file. To manually work on the master repository, you must work on the repository in a separate directory from your MUD directory. Then, you must replace both the master RPD and the latest versioned repository in the MUD directory.

For example, follow these steps to manually update a repository named master.rpd:

1. Copy the master repository (master.rpd) out of the MUD directory into a local directory.

2. Use the Oracle BI Server to make the changes necessary to the local copy of the master repository, master.rpd.

3. When manual edits are complete, copy master.rpd to the MUD directory as master.rpd. For example:

   copy c:\local\master.rpd c:\mud\master.rpd
   

4. In the MUD directory, identify the latest repository with a version number, for example, master.7011.

5. Copy master.rpd to the MUD directory and overwrite the latest versioned repository. For example:

   copy c:\local\master.rpd c:\mud\master.7011
   

Replacing the Latest Version

This example explains how to copy an older version to replace the latest version. Assume you are at version 1000 and want to roll back to version 900. In this situation, you have three files: repository.900, repository.1000, and repository.rpd, the current version. To perform the roll back, make a copy of repository.900 and rename it to repository.1001. This lets you keep repository.1000 in your version history. Then, copy repository.900 to repository.rpd.