Process for moving DOORS databases from one DOORS server to another?

I need to move a DOORS database from one existing DOORS db server to another existing DOORS db server, both running 8.3. IBM Rational has instructed me to shutdown DOORS on both servers, and then copy the content of the directory defined in HKEY_LOCAL_MACHINE\SOFTWARE\Telelogic\DOORS_Server\8.3\Config\Serverdata from one server to another.

However, this will overwrite files that have the same names on both servers. I am new to administering DOORS, but I can't see how this would be OK.

Can someone tell me what the correct process is for doing this? I haven't found what I need in either the on-line documentation or in the tech notes.
Leesa Hicks
Principal Engineer
Tektronix Instruments
Leesa_Hicks - Tue Feb 22 15:27:36 EST 2011

Re: Process for moving DOORS databases from one DOORS server to another?
Leesa_Hicks - Tue Feb 22 17:24:22 EST 2011

Update - after asking support about this again, the new instructions are that I must create a new database instance on the destination server, and that you can't combine two DOORS databases together.

Leesa Hicks
Principal Engineer
Tektronix Instruments

Re: Process for moving DOORS databases from one DOORS server to another?
PDU - Wed Feb 23 01:27:03 EST 2011

Leesa_Hicks - Tue Feb 22 17:24:22 EST 2011
Update - after asking support about this again, the new instructions are that I must create a new database instance on the destination server, and that you can't combine two DOORS databases together.

Leesa Hicks
Principal Engineer
Tektronix Instruments

Hi,

perhaps a solution :

  • archive each project of source data base
  • restore these projects in the other.

Pierre

Re: Process for moving DOORS databases from one DOORS server to another?
SystemAdmin - Wed Feb 23 02:01:12 EST 2011

If you are trying to replace a DOORS DB with another you can delete the old data structure and copy over with the new one. If you are merging two databases then you have to use the archive and restore method.

Re: Process for moving DOORS databases from one DOORS server to another?
llandale - Wed Feb 23 09:52:05 EST 2011

Pekka is right. The original instructions were correct for 'moving' which would result in two identical databases. If you want to MERGE, then it cannot be done with the file system (unless you are Mathias and willing to edit encrypted database files), but instead should be done within DOORS with archive/restore.

Archive-restore will cause you to lose all the Access Records in the moved data. There are other posts that have clumsy ways of re-storing them; although its tough unless the user names and groups of both databases line up well.

If you go that route and the moving database is small, I'd be tempted to re-arrange it such that all existing projects and now under one single master project, then archive and restore that ONE project, then un-arrange them as you see fit. You won't need to do that if none of your projects have inter-project links.

If your databases are on different DOORS servers, then it would be a lot quicker to create a 2nd temporary database on the away server, move the old database there, THEN perform the archive-restore on that away server; then delete the temp database.

  • Louie

Re: Process for moving DOORS databases from one DOORS server to another?
Leesa_Hicks - Wed Feb 23 11:56:30 EST 2011

llandale - Wed Feb 23 09:52:05 EST 2011
Pekka is right. The original instructions were correct for 'moving' which would result in two identical databases. If you want to MERGE, then it cannot be done with the file system (unless you are Mathias and willing to edit encrypted database files), but instead should be done within DOORS with archive/restore.

Archive-restore will cause you to lose all the Access Records in the moved data. There are other posts that have clumsy ways of re-storing them; although its tough unless the user names and groups of both databases line up well.

If you go that route and the moving database is small, I'd be tempted to re-arrange it such that all existing projects and now under one single master project, then archive and restore that ONE project, then un-arrange them as you see fit. You won't need to do that if none of your projects have inter-project links.

If your databases are on different DOORS servers, then it would be a lot quicker to create a 2nd temporary database on the away server, move the old database there, THEN perform the archive-restore on that away server; then delete the temp database.

  • Louie

This is very helpful, thank you.

I have a small DOORS database that I would like to merge into a larger one. I'll look into the archive/restore process.

Leesa Hicks
Principal Engineer
Tektronix Instruments

Re: Process for moving DOORS databases from one DOORS server to another?
SystemAdmin - Wed Feb 23 17:00:23 EST 2011

Leesa_Hicks - Wed Feb 23 11:56:30 EST 2011
This is very helpful, thank you.

I have a small DOORS database that I would like to merge into a larger one. I'll look into the archive/restore process.

Leesa Hicks
Principal Engineer
Tektronix Instruments

Louie has identified two issues to watch out for with archive/restore - namely loss of specific access rights and loss of inter project linking if all interlinked projects are not included in the archive.

A couple more to be aware of are problems with the DOORS Change Proposal System add-on (if you're using it) and any views that contain columns created by the Analysis Wizard.

DOORS CPS
Users that have been given a role in the CPS are identified within CPS modules by their unique user DB ID number (a hex number). If an archive of a project that has been using the CPS is restored onto a different target DB - these unique user ID numbers will be mapped to whatever is on the target DB - so whilst user 0000001B on the originating DB might map to John Smith, user 0000001B on the other DB is most likely mapped to someone completely different or no one at all if the number of users on that DB haven't got up to that hex number yet or that user has been deleted.

Analysis Wizard Columns
If the Analysis Wizard has been used to display link traceability with specific source or target modules (as opposed to any linked source\target module), then the DXL layout code used in these columns will have identified these modules by their assigned unique DB ID numbers and not by path\name. As for the CPS above, these unique DB ID numbers will either map to the wrong modules or more than likely, not at all, on the target DB. It's also possible that DXL Attributes may contain the same problem as some people convert DXL layout code into DXL Attributes.

If either of the above are true in your case, please respond, as myself, and I'm sure others, have had past experience with archive\restore issues like this and can pass on some ideas and maybe some DXL utility scripts to help.

Paul Miller
Melbourne, Australia

Re: Process for moving DOORS databases from one DOORS server to another?
Leesa_Hicks - Wed Feb 23 19:56:24 EST 2011

SystemAdmin - Wed Feb 23 17:00:23 EST 2011
Louie has identified two issues to watch out for with archive/restore - namely loss of specific access rights and loss of inter project linking if all interlinked projects are not included in the archive.

A couple more to be aware of are problems with the DOORS Change Proposal System add-on (if you're using it) and any views that contain columns created by the Analysis Wizard.

DOORS CPS
Users that have been given a role in the CPS are identified within CPS modules by their unique user DB ID number (a hex number). If an archive of a project that has been using the CPS is restored onto a different target DB - these unique user ID numbers will be mapped to whatever is on the target DB - so whilst user 0000001B on the originating DB might map to John Smith, user 0000001B on the other DB is most likely mapped to someone completely different or no one at all if the number of users on that DB haven't got up to that hex number yet or that user has been deleted.

Analysis Wizard Columns
If the Analysis Wizard has been used to display link traceability with specific source or target modules (as opposed to any linked source\target module), then the DXL layout code used in these columns will have identified these modules by their assigned unique DB ID numbers and not by path\name. As for the CPS above, these unique DB ID numbers will either map to the wrong modules or more than likely, not at all, on the target DB. It's also possible that DXL Attributes may contain the same problem as some people convert DXL layout code into DXL Attributes.

If either of the above are true in your case, please respond, as myself, and I'm sure others, have had past experience with archive\restore issues like this and can pass on some ideas and maybe some DXL utility scripts to help.

Paul Miller
Melbourne, Australia

We are using LDAP authentication, so does each user still have a unique user DB ID number?

If I do try the archive/restore process, I would include all existing projects in the database to be moved.

I think the safest thing to do at this point, particularly since I only have two days to do it, is to create a second database on the existing server and then analyze whether it makes sense to try to merge the second db into the original one.

Leesa Hicks
Principal Engineer
Tektronix Instruments

Re: Process for moving DOORS databases from one DOORS server to another?
Dhansoia - Wed Feb 05 21:28:13 EST 2014

Hi Paul,

We are in the process of merging 2 doors databases. The approach we have in mind is to migrate the data folder of one of the databases to the new server and use archive and restore for the second database. I see the following issues with archive and restore:

- Links running across doors projects. Here I was thinking of creating a new parent project and move the projects containing the source, target and link modules under it and archive and restore this parent project and then move them to desired location on the new server. Our projects are large and is there smoe issue with archiving and restoring large projects. Also will the access rights on the projects get affected when I move them under this new parent project.

- If I already created the users and groups for the second database on the new server and then archive and restore the projects, will it preserve the access rights on projects and modules that are restored on the new server.

- We do have DXL Layout columns created using the wizzard that rely on the module URI. Archiving and restoring will change the module URI's and we will have to edit all these DXL Layout colums to point to the new URI's. If you have some DXL scripts to address this, it would really help us.

Any other pitfalls you see. We do not use CPS but we have another nightmare to address. We use QCI to sync doors requirements to HP QC and not sure how the integration will get affected if the module URI's chnage due to archive and restore. Do you have any experience on this.

Re: Process for moving DOORS databases from one DOORS server to another?
llandale - Fri Feb 07 11:52:51 EST 2014

Dhansoia - Wed Feb 05 21:28:13 EST 2014

Hi Paul,

We are in the process of merging 2 doors databases. The approach we have in mind is to migrate the data folder of one of the databases to the new server and use archive and restore for the second database. I see the following issues with archive and restore:

- Links running across doors projects. Here I was thinking of creating a new parent project and move the projects containing the source, target and link modules under it and archive and restore this parent project and then move them to desired location on the new server. Our projects are large and is there smoe issue with archiving and restoring large projects. Also will the access rights on the projects get affected when I move them under this new parent project.

- If I already created the users and groups for the second database on the new server and then archive and restore the projects, will it preserve the access rights on projects and modules that are restored on the new server.

- We do have DXL Layout columns created using the wizzard that rely on the module URI. Archiving and restoring will change the module URI's and we will have to edit all these DXL Layout colums to point to the new URI's. If you have some DXL scripts to address this, it would really help us.

Any other pitfalls you see. We do not use CPS but we have another nightmare to address. We use QCI to sync doors requirements to HP QC and not sure how the integration will get affected if the module URI's chnage due to archive and restore. Do you have any experience on this.

Yes, a master Project holding the other projects for Archive and Restore; assuming those other projects have inter-project links.

Yes, you have a DXL Layout problem (unless they fixed that).

Yes, I suppose you have a QCI problem.

No, creating the named Users and Groups won't help.  The restored project will have everything "Inherited".  This is because an AccessRecord contains the user/group ID associated with it, not the name.  So user "Joe" in the old data base will have a UniqueID different than in the new.  You will need to dump all the accesses in the old database and then re-apply them in the new.  Yuuuuck.

Consider just having two databases on the same new server.

-Louie