Considerations for upgrading from a stand-alone server to a central server

To upgrade from a stand-alone server to a central server, you must select a central CR database. Then, you must migrate all existing CRs into the central CR database. A central server offers many benefits. However, sometimes it is not the correct choice for all users. Read this entire section so that you understand all of the caveats before upgrading to a central server. When you have upgraded, you cannot revert to a stand-alone server.
Attention: Do not use a central server if you use any of the following queries, interfaces, or relationships:

Certain nested queries

In central server mode, CRs and tasks are stored in separate databases, which impact the types of queries you can run on the different databases. Your central CR database contains only CRs. As a result, you cannot use query strings that bridge the relationship from CRs to tasks.

For example, the following query string would not return accurate results:

has_associated_task(cvtype='task' and release='1.0') and crstatus='assigned'

Queries in your development databases are not as limited. CRs are not created in development databases. However, ghost CRs are created in the development database.

With ghost CRs, a Rational Synergy Task Folder, in a development database, can still rely on a query, such as:

is_associated_task_of(cvtype='problem' and release='1.0' and crstatus='resolved')

With ghost CRs, you can continue to use most CR-to-task nested query strings for CR-based Update Members. However, they have limitations. Ghost CRs only maintain the attributes they have been told to sync, though you can sync as many attributes as needed for your queries. They do not maintain any relationships beyond associated_task, and they exist only for CRs that have associated tasks. Besides their use in Update Members, ghost CRs can also be queried for through the Rational Synergy CLI, but they cannot be edited there.

Most other ways of traversing between CRs and associated tasks continue to work as always. These ways include Queries and Reports using report formats with associated tasks, Relationship Reports to associated tasks, the associated tasks control on Show Forms, and the Change Requests Explorer in Rational Synergy.

The Rational Change for Rational DOORS Interface

The IBM Rational Change for Rational DOORS® Interface does not support transferring CRs between databases. If you are already using this product, you cannot migrate your existing CRs to a central CR database. If you do not currently use the interface, you can use the interface after you upgrade to a central server.

The CreateMiscObject API

This API creates misc objects that cannot be transferred to other databases. If you have used this API to create misc objects related to CRs, you must first delete those objects or unrelate them from your CRs. Otherwise, you cannot migrate your existing CRs to a central CR database.

Uncommon CR relationships

When you migrate your existing CRs, the CRs and their directly related objects are transferred to your central CR database. If any of those objects must remain in their current development databases, do not migrate. Normally, CRs are only directly related to other CRs, attachments, and tasks. This setup is safe to migrate. However, if you have created any direct relationships from CRs to other objects, those objects would be incorrectly transferred. Unsupported relationships that do not work in a central server include these examples:


Feedback