![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Retreating from Section/Shareable edit Topic Summary: Created On: 1-Mar-2004 14:55 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
We have a module which has grown significantly in terms of objects and especially number of attributes since its creation some 2-3 years ago. At some point (before my time), somebody decided to try using shareable sections. Since I know the module since I started work on it some 9 months ago, it suffers from long loading/saving times and relatively frequent module corruption.
After one of the incidents, Telelogic Support had a look at our file listings (from the database server itself) and could conclude no more (without looking at the module itself) than that we must have a number of shareable sections. The questions is: is it possible to go back, as we almost never need this feature? Thereby reducing the number of files managed by DOORS for this module. Thanks if anybody can share their experience. Pieter de Waard ------------------------- Pieter de Waard www.nhindustries.com |
|
![]() |
|
![]() |
|
Pieter,
I'm not sure what version of DOORS you are using. Under DOORS 5.2 I have been told by a telelogic representative that even reducing the number of sharable sections in a formal module does not get the performance back. That is because when you create sharable sections, DOORS will split the sections up into "Lockable" files, and even when you reduce the number of sections, DOORs does not reduce the number of lockable files. I have seen long load times significantly reduced by performing a baseline on a module. Performing baselines archives the history records, thereby reducing "Load times" I'm not sure if making a copy (or clone) of a formal module could help your "sharable sections" problem either. Just some thoughts...hope it helps. |
|
![]() |
|
![]() |
|
In contrast, we actually use lockable sections in order to reduce save times.
When you save a module in exclusive edit mode the whole module seems to get saved regardless of the number of changes. This takes a long time for large modules. Saving a locked section is significantly faster. When you create lockable sections, the number of files used for that module in the database increases. Once you have created the lockable sections, you can undo them by resetting the access rights, but this does not change the database file structure back to what it was before. If you really want to remove the lockable sections and reduce the number of database files, then you have no choice but to make a new copy of the module and restore all the links. ------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
If you save each module in full edit mode then you will cut down on some of the many database files that were created when edit shareable mode was implemented - files associated with history and session information have their contents rolled into the related main DOORS database files when you do the full save, and the associated small files will be removed from the database. However other files are left behind (t*.dtc files) and I dont recommend any manual editing be done at database level.
Have you baselined your module recently - that helps performance, as does purging deleted objects. Customer support have a document covering how to improve your performance which may be of help to you. If you cannot share your data it is difficult to pinpoint what could be causing data corruption. Mandy |
|
![]() |
|
![]() |
|
Thanks for the response so far.
We are running DOORS 5.2, we baseline on a regular basis, and we purge some time (however, the need for purging in this specific module is limited, as we are past the stage of deleting objects). We would be interested in the document by customer support on how to improve performance. I will ask for that. If copying the module does not help, we are thinking of regenerating the module, in the process maintaining structure and IDs. Maybe DOORS 7 will offer some solace? ------------------------- Pieter de Waard www.nhindustries.com |
|
![]() |
|
![]() |
|
Hi Pieter,
if you still want to get rid of the shareable setup you have to reset the permissions to 'inherited'. Setting up a module for 'shareable edit' does nothing else than breaking the inheritance of access rights. Thus, I always recommend to do that manually rather than using the DOORS standard set-up functionality. The following script does this reset: // resets all object permissions to inherited /* all object permissions are reset to inherited, thus removing the share setup. */ Object o Module m = current bool inac string err if (!isEdit(m)) { errorBox("open in exclusive edit mode first !") halt } for o in entire(m) do { err=isAccessInherited(o,inac) if (!null err) { print "Error:" err "\n" continue } if(!inac) { err=inherited(o) if (!null err) { print "Error:" err "\n" } } } Hope that helps, Bernd ------------------------- Dr. Bernd GRAHLMANN Requirements Management & DOORS consultant Cell : +33 6 82 86 68 03 Fax : +33 6 83 86 18 01 e-mail: Bernd@Grahlmann.net www.grahlmann.net |
|
![]() |
|
![]() |
|
Hi Bernd,
Thanks for your script. Will certainly use it, although I'm pretty sure that the sections no longer exist when looking via the normal user interface. The possibility remains however that the database file structure is not reset to a "non-shareable state", in view of the other postings on this thread. - Pieter ------------------------- Pieter de Waard www.nhindustries.com |
|
![]() |
|
![]() |
|
In older versions of DOORS creating a shared section (and saving) would PERMANANTLY fragment the module; even if you then reset the section. I hate it when that happens. I have heard rumors that the newer versions [1] Partially clean it up if you Edit the module, make a tiny change, and save it, or [2] when you Erase the sections.
- Louie |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.