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 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.
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.
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:
Rational Synergy has features to show which CRs are included in a baseline. These features do not rely on relationships and continue to work in central server mode.