![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Invisible In Links??? Topic Summary: Created On: 6-Sep-2007 14:45 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
OK so here's an interesting one. ------------------------- Scott Boisvert Engineering Tools Administrator L-3 Communications - Avionics Systems scott.boisvert@l-3com.com Edited: 6-Sep-2007 at 14:48 by Scott Boisvert |
|
![]() |
|
![]() |
|
OK...the DXL script temp fix doesn't work any more...lol...
------------------------- Scott Boisvert Engineering Tools Administrator L-3 Communications - Avionics Systems scott.boisvert@l-3com.com |
|
![]() |
|
![]() |
|
Scott,
I've seen this before and it is an access rights issue--at least it was with me. Are you SURE that the link is going through the correct link module? What does logging in as Administrator show you? ------------------------- Kevin Murphy http://www.baselinesinc.com The Requirements Management Experts Edited: 6-Sep-2007 at 17:13 by Kevin Murphy |
|
![]() |
|
![]() |
|
Weird.... Yup checked the link module for the links...correct one. ------------------------- Scott Boisvert Engineering Tools Administrator L-3 Communications - Avionics Systems scott.boisvert@l-3com.com |
|
![]() |
|
![]() |
|
This was an old v5.1 or was it v6.1 bug. The solution was to go to the source module and re-access all the links, then save that module even though you didn't change anything. That made the link indicators re-appear in the target module.
We never tracked down the root cause of the problem; but I haven't seen it in years suggesting it hasn't been a problem for us in v7.1 or v8.1. Attached find an old script I wrote to indiscriminately redisplay links by opening all modules in the current folder and below for edit, open all their outlink partners edit, access all the links, then save all the modules. You'll have to comment out the lnclude file and deal with the library functions (which start with "f"), but I browsed and you should be able to figure it out [1] use 'edit' instead of fOpenModule [2] use 'print' instead of fErrLogAdd [3] ignore the fStatus functions. The idea was to run that script on all projects in the database, but you could perhaps be more selective, running it only in folders that you know source such invisible links. One nagging problem I'm having is that my memory of this issue involves only opening the source module edit, looping through the objects and all outlinks, then saving and closing. I have no memory whatsoever about opening all the target modules edit. - Louie |
|
![]() |
|
![]() |
|
I have a similar situation in which the links UNFOLD the further I scroll down.
Yet, the objects at the top of the link module STILL sare not the entire list of requirements in the Linking I have performed. Why is this? To be specific, there are 10 links, 5 up and 5 down when I first open the Link Module. When I scroll down, the requirements on the left from one formal module begin appearing, and 20 ...10 up and 10 down.....requirements from the other formal module appear at the top. However, even though all the linking requirements are shown for the specification on the bottom, no more than 20 requirements from the other specification show up at the top. What's wrong? How can I make them appear? ------------------------- He who would swap his freedom for the promise of security deserves neither. |
|
![]() |
|
![]() |
|
Are you talking about what you see when you open the link module? ...
The link module matrix view seems hopeless to me. All objects in the source module along the left and all the objects in the target module along the top. That's a huge matrix. The view only shows what fits on the screen, which is usually a very small %age of objects. If each module has only 100 objects and you can see 20 object in each module, you can see only 20x20=400 interactions out of 100x100=10,000 possible ones. Scrolling around in the link module is a hopeless way to find links. Also, you can only see one link module at a time. Of links are in more than one link module you won't see the others. Viewing the link module is ony useful when you want to delete a whole bunch of links (delete a link set), or when you want to create link-attributes. - Louie |
|
![]() |
|
![]() |
|
Scott - This sounds similar to an old version 4 bug that would show a modules in-links (or outlinks) as missing. In ver 4 a fix was to go into the current.ver on the server and blow away the .LNK file associated with the target module (assuming that you were missing the incoming links) or both source .LNK and target module's .LNK (assuming you were missing the outgoing links) then recreate the links. ------------------------- - Kristen |
|
![]() |
|
![]() |
|
I am having a problem very similar to this one in DOORS 8.1.
I have three parallel child/parent modules, with hefty linkset restrictions allowing only links with the following: Child1 -> Parent1 Child2 -> Parent2 Child3 -> Parent3 However, when I open parent 1, I see the following on the in-link arrow: Parent 1, Object 17: <- Child1, Object 2 (This is expected) <- Child2, Object 2 (Not real) <- Child3, Object 2 (Not real) The two extra links are from modules that aren't in the linkset pairing, and are often from objects that have been deleted--and certainly were never linked to Parent 1 in the first place. Moreover, the source object number is always the same as the legitimate in-link. These "ghost" links disappear intermittently. I believe they are part of some sort of internal module link cache, which DOORS updates in seemingly random ways. It is apparently the same cache used by the "for (LinkRef_ l) in Module" loop, as these links are visible to that loop as well (but not to "For Link l in Module" with the source open). The following actions predictably cause the ghost links to disappear from the inlinks arrow (and any display DXL columns referencing them) until the module is closed and re-opened: opening the supposed source module and running a DXL with "for Link l in obj do", opening the target object's properties, or opening the link module containing the legitmate link and viewing the linkset. I can partially confirm that Louie Landale's solution works in DOORS 8.1. I did not use his script, but opening the source module in edit, accessing every link, and saving the source module (with no changes) did clear up the problem. However, it took a few tries. I found that my script needed to actually access some information about the link (I used "print targetAbsNum(l)" ), and that the target object needed to run through its links as well. I hope this is helpful to people who encounter the problem in the future. |
|
![]() |
|
![]() |
|
I am having exactly the same problem as the OP - random invisible in-links in the target module. These were all visible when the links were created, and found missing when opened at a later date.
Opening the link properties from the source module in turn and re-saving the source module appears to fix them permanently. The access rights are ok. I am using DOORS Client version: 8.1.0.2, Server version: 8.1.0.0. Is there a better way of fixing this, i.e. the root cause? Is there a way to check I've not missed any links I need to fix manually? |
|
![]() |
|
![]() |
|
We have seen a very similar problem -- a module, A, showed incoming links but when following to the source, B, the other object did not display the outlink to the first module A. Some monkeying around to access the links (traceability view in the original target module A, e.g.) would cause the inlinks to stop showing. However, upon closing both and reopening the target A, they showed up again.
I had tried the suggestion to access info about the links, then save with no actual changes, but it did not seem to help. I talked quite extensively with Telelogic support, who sent me a "Fix Links" script to try. The script did not find anything for it to fix, though. I then tried opening both modules edit and running more extensive DXL to check source or target of each link, and opened the source module of each incoming linkref. Then I saved both (a couple of times, actually). What do you know, the problem has disappeared! Thanks to all for the tips. We are using 8.1.0.6, but were previously on 7.1 (I forget which patch). The original source module B had been copied from a module in A's project that had links to A. I do not know if the links were copied intentionally or not, but if not they were deleted early as I can find no trace nor history records of them in the earliest baseline. As far as root cause, Telelogic said that this can happen when there is a network interruption, or a computer crash, or similar, while in the process of making/deleting links or copying. Interestingly, I just got another script from support -- "inlinks.dxl", dated 2001 and written for DOORS 5.2. It works on either case: an outlink with no corresponding inlink, or an inlink without its outlink. The interesting part is that its fix seems to be the same as Scott's. I think it recreates link in the first case, and creates then deletes a link in the second. At any rate, I'm glad it's fixed now (edit: for us). Chris Edited: 27-Jun-2008 at 23:53 by Chris Jones |
|
![]() |
Telelogic DOORS
» Administration
»
Invisible In Links???
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.