![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Trigger Delay Topic Summary: Created On: 26-Apr-2004 22:58 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: "...and chasing a quirk that you'll probably never get to the bottom of, and really doesn't matter in the big picture". Am I that transparent? - Louie ![]() | |
![]() |
|
Deployed a DB trigger. It runs ok.
Loaded two doors, [1] and [2] Using [1] removed the Trigger. Verified it was gone. Window [2] still fired the trigger. However, when I confirmed in this window the trigger was not present and stopped triggering. It appears there is either some delay in posting triggers, or each DOORS Explorer tends to load all the relevant Triggers (perhaps when you change Folders or Projects) and does not notice when one was removed. Anybody else see this odd behavior? - Louie |
|
![]() |
|
![]() |
|
Louie,
I have seen some interesting things with triggers. There are three categories of triggers. 1.Database 2. Project 3. Module I found that if you create a project trigger you will not may see it when you look for the database triggers etc. but may not be able to delete it. I have not tried this for all permutations. But, my belief is that you need to use all 3 looping constructs and see what you come up with. |
|
![]() |
|
![]() |
|
I can't say I'm surprised by the symptoms you've described. I'd expect a DB trigger to be loaded when the DB is loaded, and then to run whenever triggered (because it's loaded). I'd expect that, if that trigger was removed by a second instance of the client, the trigger would remain in the first instance until there was some specific client activity to access it (like confirming it's existence, or attempting to edit it, or whatever). Then I'd expect it to not be there, even though it had previously fired after being removed from the other instance.
I don't actually think this is a problem. The overhead involved in checking whether the trigger still exists (after it's been loaded) every time the opportunity arises to fire it, would slow the whole system down to a snail's pace. There has to be some compromise if the system is to run at acceptable speeds, and this seems like a reasonable one. Sticking my pragmatist hat on ![]() ------------------------- Paul dot Tiplady at TRW dot com TRW Automotive |
|
![]() |
|
![]() |
|
Triggers defined as "project-all" are stored in the DB. Other sorts are stored in the current project or current module. Yes, looping through the current project's triggers will NOT find DB stored triggers.
- Louie |
|
![]() |
|
![]() |
|
"...and chasing a quirk that you'll probably never get to the bottom of, and really doesn't matter in the big picture".
Am I that transparent? - Louie ![]() |
|
![]() |
Telelogic DOORS
» Administration
»
Trigger Delay
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.