![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Rogue Module Locks Topic Summary: Locks not found by getLocksinDatabase Created On: 31-May-2006 18:02 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
We have a problem that arises roughly once a month with an automated dxl script trying to remove all locks. getLocksinDatabase will return no locks; however, there will be a 'rogue' lock on a module. When this module is opened for modification, during the automation, the warning pops up and the process hangs. I have been unable to recreate this with any consistency. Has anyone run into this issue? Is there a reason certain locks will not show up with the getLocksinDatabase method? |
|
![]() |
|
![]() |
|
For a LONG while I used such a script to unlock everything, before the script did the routine project archives. I never had a problem that stopped the archive from working.
I assume you are doing something like this: LockList llist = getLocksInDatabase(true) [1] This will not get locks of the current user's currently opened modules. Be sure the script closes all modules before getting the lock list: for mod in database do close(mod, false). Actually loop through the list 3 times to insure everything gets closed (links may keep things open against your will). [2] This will not get locks, I don't believe, for items to which the user doesn't have 'R' access. [3] There MAY be a problem if an active user currently has the module open. The guts of my program went like this: llist = getLocksInDatabase(true) for lockItem in llist do { ErrMess = remove (lockItem) } - Louie |
|
![]() |
|
![]() |
|
Yes, we are getting the locks with the getLocksInDatabase(true) function.
[1] Presently, we are not closing modules prior to removing locks. We will try to implement this. [2] The script is run by an account with permissions to all modules, so this shouldn't be an issue. [3] We have been able to track the problem to a person currently logged in once, but they got to work and logged out before we got anywhere. Is there any solid word from Telelogic on this kind of limitation? |
|
![]() |
|
![]() |
|
Timing might be your problem if you noticed that a user has opened a module when the automation dxl was running.
1. If your dxl is running and someone opens a module in edit mode and then your dxl tries to open it in edit mode, there will be a problem. You need some sort of error checking function when you try to open modules with an automation dxl. Your error function could also provide the user name,etc. 2. This can also happen when someone has a view that includes a layout or attribute dxl that opens a linked module in edit mode. 3. When the DOORS client is installed, I used to set the registry so that the default mode was read-only. ------------------------- Cliff Bly |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Rogue Module Locks
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.