Moving defects between different projects

  • Questions
  • Moving defects between different projects
Question ID: 104768


I am trying to import defects (ALM 11) from one project to another without using the UI. So far we copied the bugs from the BUG table in one project over to the other the BUG table on the other project using SQL server management studio. The problem is that we are able to see the defects in the project that we moved them to. The problem is that we are unable to view the attachments in the defects even though the defect shows that it has attachments. We even went in and manually copied the attachments from the original repository over to the second repository. Why can't we see the attachments in these defects?

Marked as spam
Posted by (Questions: 91, Answers: 0)
Asked on December 18, 2012 7:38 pm
Answers (1)
Private answer

**NOTE: First of all I would highly suggest against moving defects in this manner. The proper way to do this would be to use copy and paste or HP synchronizer to accomplish this. There is a very real danger that you could corrupt your project by performing this. With that being said, before making any changes be sure that you have backup copies of all projects involved. Since the introduction of the smart repository, moving defects from the backend is very difficult to pull off.**

The cross reference table is the table that handles attachments for entities including defects. The reason that you are seeing the Attachment title bolded is because the attachment flag is turned on for the entity in the Bug table, but when QC looks in the Cross_Ref table to find the attachments and what the attachment is called there is nothing to populate since the table is empty.

What you will probably need to do is go back to the project that you originally took the defects from and copy the contents of the Cross_Ref table where the CR_KEY_1 = ''the defect #'' and CR_ENTITY = ''BUG''

This will only make the attachment show up in the UI however there are still other tables that would need to be modified for the attachment to actually reference the correct file in the smart repository. You would also need to add the file in the repository to the two tables below

SMART_REPOSITORY_LOGICAL_FILE (This table contains the logical name of the file as it shows up when selected in the defect as ''SRLF_NAME'' field also dictates what size, time, etc the attachment shows in the UI of the defect and most importantly links to the ''SRLF_PHYSICAL_ID'' which identifies the actual location of the file in the SMART REPOSITORY in the ''SMART_REPOSITORY_PHYSICAL_FILE'' table)

SMART_REPOSITORY_PHYSICAL_FILE (this table points to where the file is actually located in the repository)

So you basically need to get these 4 tables to line up to actually be able to open the defect in the UI:

This is going to be fairly difficult to pull off it would be possible, but really the only way you can do this is to have your DBA write some complex queries. HP doesn't really support this backdoor method of adding to the repository since the introduction of the smart repository. The smart repository may have the same file in the SMART_REPOSITORY_PHYSICAL_FILE table being referenced by multiple entities in the SMART_REPOSITORY_LOGICAL_FILE table to save space, so this is why the file in the repository is no longer named literally and it is more difficult to re-reference the attachments in an entity copied from one DB to another.

Marked as spam
Posted by (Questions: 0, Answers: 340)
Answered on December 18, 2012 7:41 pm
Thanks, I ended up just copying and pasting which was much easier then what I was originally trying to do, thanks for the info.
( at December 20, 2012 10:18 pm)