Number of in-linkRefs different to number of in-link

Hi everybody,

I am experiencing a problem with incoming links and I am not able to solve it.

I have module A with test cases which is being linked from several modules B with test procedures. The links goes from objects in B to A. I have to obtain a traceability matrix which has to determine object in test case (module A) in which modules B have been used. I didn't want to open modules B so I have coded a DXL so that if I obtain the linkRef I can obtain the name of the source module.

LinkRef lref

for lref in o<-"*" do
   {
  
      string sm = fullName(source lref)  // get source module name, 
     }

It seems that there are objects in module Bs that have been deleted and purged in the past.  As they are purged DOORS should have deleted linkRefs in object in A but it seems there has been any problem with DOORS and linkRefs are still in A. I have coded another DXL so that I can count number of linkRefs of an object. And then I open source modules and count  in-links of this objects and I have found that I have several objects with different number of linkrefs and links of the incoming links, i.e 19 linkRefs 11 links. Then it seems it updates linkrefs and the second time I run the DXL with all the modules still opened linkrefs and links are the same 11 linkRefs 11 links. I have saved all the modules, closed my DOORS client and started it again and the problem still persists 19 11 and 11 11 the seconde time.

I have found a DXL in https://www.ibm.com/developerworks/forums/thread.jspa?messageID=14424356&#14424356

And I have run the attachment_14434376_inlinks.dxl and I find several errors in the same object and get the following log


No matching source object found for inlink in object 924955.
No matching source object found for inlink in object 924955.
No matching source object found for inlink in object 924955.
No matching source object found for inlink in object 924955.
No matching source object found for inlink in object 924955.
No matching source object found for inlink in object 924955.
No matching source object found for inlink in object 924955.
No matching source object found for inlink in object 924955.

Object TCSIS_ETCS_923924955 - 19 incoming links processed.

The DXL that counts linkRefs and links is telling me 19 linkrefs and 11 links, which corresponds to what the counter of linkRefs and links found.

How can I solve this problem? Can anyone help me please? It seems the objects have been purged but in the target the linkrefs of the incoming links have not properly been updated and I do not really know how to update those linkrefs.

Thanks in advance,

             Silvia

 


SilviaMT - Thu May 14 16:38:41 EDT 2015

Re: Number of in-linkRefs different to number of in-link
EHcnck - Fri May 15 13:58:45 EDT 2015

Have you tried creating a new link from source to target then save to force DOORS to refresh the link info? This should resolve your issue, then you can delete the link you just created to force the refresh.

 

-Jim

Re: Number of in-linkRefs different to number of in-link
llandale - Wed May 27 18:24:47 EDT 2015

I have no new thoughts since that old thread.  My script on that thread (I notice) opens all the modules "edit" and saves them afterwards.

I think you can identify my native functions (not included) and re-code them accordingly.  change fErrLogAdd to "print" and fOpenModule to "edit".

-Louie

I wonder if opening the last few baselines would help...

Re: Number of in-linkRefs different to number of in-link
SilviaMT - Thu May 28 02:02:56 EDT 2015

EHcnck - Fri May 15 13:58:45 EDT 2015

Have you tried creating a new link from source to target then save to force DOORS to refresh the link info? This should resolve your issue, then you can delete the link you just created to force the refresh.

 

-Jim

Thanks Jim,

I am not able to recreate the link as the source object has already been deleted and purged.

            Silvia

Re: Number of in-linkRefs different to number of in-link
SilviaMT - Thu May 28 02:10:51 EDT 2015

llandale - Wed May 27 18:24:47 EDT 2015

I have no new thoughts since that old thread.  My script on that thread (I notice) opens all the modules "edit" and saves them afterwards.

I think you can identify my native functions (not included) and re-code them accordingly.  change fErrLogAdd to "print" and fOpenModule to "edit".

-Louie

I wonder if opening the last few baselines would help...

Hi,

I finally opened a PMR and it seems the only way to solve this error is sending the inlinks.dtc of the module with erroneous linkRef and indicate which references have to be deleted. There is no DXL to fix the problem.

It seems this error has been in our database since we deleted the source object as there was an error in version DOORS 8.3 related to this issue that link references were not deleted the source object were purged.

I created a DXL to check how many modules have this kind of errors and there were 12 modules that should be fixed. By the momento, I finally had to change my DXL to obtain the matrix taking into account only link information from the source object is correct. And asap I will send the modules that should be fixed by IBM support.

Thanks,

             Silvia

Re: Number of in-linkRefs different to number of in-link
llandale - Thu May 28 16:21:04 EDT 2015

SilviaMT - Thu May 28 02:10:51 EDT 2015

Hi,

I finally opened a PMR and it seems the only way to solve this error is sending the inlinks.dtc of the module with erroneous linkRef and indicate which references have to be deleted. There is no DXL to fix the problem.

It seems this error has been in our database since we deleted the source object as there was an error in version DOORS 8.3 related to this issue that link references were not deleted the source object were purged.

I created a DXL to check how many modules have this kind of errors and there were 12 modules that should be fixed. By the momento, I finally had to change my DXL to obtain the matrix taking into account only link information from the source object is correct. And asap I will send the modules that should be fixed by IBM support.

Thanks,

             Silvia

Lets bring Frankenstein back to life by attaching 120v electrodes to the connectors on his neck.  You may want to practice this on an archived-restored version of the project.

  1. open the target module edit
  2. open all the source modules edit
  3. for an offending target object
  4. ... delete all the inlinks
  5. ... delete the object
  6. save and close the target module
  7. close WITHOUT SAVING all the source modules
  8. open the source modules read
  9. open the target module edit
  10. undelete the object.
  11. check it out

You could also try deleting the link-set instead of deleting the links; close the link module WITHOUT SAVING.

I'm also wondering about all the "versioned" link stuff may be apparently causing a problem.  I never use that.

-Louie