Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
Topic Title: Partitions
Topic Summary:
Created On: 19-Nov-2003 18:50
Status: Post and Reply
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 19-Nov-2003 18:50
User is offline View Users Profile Print this message


Mary Pupa

Posts: 11
Joined: 19-Nov-2003

We are planning on partioning some of our project. Has anyone had any experiences good/bad using partitions.
Report this to a Moderator Report this to a Moderator
 19-Nov-2003 18:58
User is offline View Users Profile Print this message


Amy Wesley

Posts: 12
Joined: 18-Oct-2002

Hello Mary,

In version 5.2 of DOORS, we used partitions and found it difficult because it doesn't really work when both the "home" database and the "away" database need to make changes to their respective modules within the partition. In our case, our customer was the home database and in the partition there was a module containing their requirements and there were a few empty modules which they set up for us to populate with our requirements and then link our requirements to theirs. We had Read access to their module and they had Read access to ours. We would add data to the empty modules and then, on a pre-arranged schedule, we would send synchronizations back to the customer so they could see what we had done. But, at one point in time, they needed to make a change to one of their requirements in their module. The only way to allow this was to do a rejoin of the partition, then re-issue the partition. When we did that, the links were duplicated and we lost full access to the data in our modules. This is because the rejoin process basically takes all of the modules and turns them over with full control to the home database.

Ultimately, we ended up dropping it. However, take my story with a grain of salt - I have heard that there have been success stories out there with using partitioning.

Hope this helps.

Amy Wesley
Visteon Corp.
Dearborn, MI USA
1-313-755-5126
awesley@visteon.com



-------------------------
Amy Wesley
Visteon Corp.
Dearborn, MI USA
1-313-755-5126
Report this to a Moderator Report this to a Moderator
 20-Nov-2003 11:59
User is offline View Users Profile Print this message


Andrea Cini

Posts: 5
Joined: 23-Oct-2003

We’re experiencing a similar adventure with DOORS 5.2, with good satisfaction.

We’re managing by DOORS a big project with more than 10,000 requirements. Our suppliers manage their requirements with DOORS as well. They use partitions originated in our DOORS instance and storing only the requirements they write. In addition, they use archive copies of our requirements restored in their away database as the input of their tasks. So, at their away databases the suppliers are able to both write requirements and link them to the parent ones.

When a synchronisation has to be done, the supplier produces the synch file and an additional ASCII file storing the link pattern between parent (ours) requirements and derived (supplier’s) requirements. This ASCII file is produced by a DXL macro. At the home database, we use the synch file to update requirements, the ASCII file to update links, by a further DXL macro.

If an update is needed from us towards a supplier, we make an archive copy of the new requirement module to be restored at the away database, links are not lost provided that they are dumped into an ASCII file before restoring and reloaded after restore.

This is working well now with one external supplier, we’re about to activate the second within a few days.

Regards


-------------------------
Andrea.Cini(at)libero.it
Report this to a Moderator Report this to a Moderator
 20-Nov-2003 14:00
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

When your "restore" a module, the module's access rights are set to 'Inherited' as are all the objects (thus losing any shared sections you had). Attribute Type/Def/Val and View access rights are NOT reset to inherited. When you move module's around via partition/rejoin, you exercise the "restore" functions, thus it is no surprise that you have lost your 'Specific' access rights.

- Louie
Report this to a Moderator Report this to a Moderator
 20-Nov-2003 16:01
User is offline View Users Profile Print this message


Hazel Woodcock

Posts: 38
Joined: 4-Oct-2002

There is a warning hidden away somewhere to not mix partitions and the change proposal system. I did this once and it was a traumatic experience. You get a corruption of the database and have to have to explain yourself to the ever helpful support staff. They were very good about fixing it, but it is not a good thing to try.

-------------------------
Hazel Woodcock
Report this to a Moderator Report this to a Moderator
 29-Nov-2003 10:24
User is offline View Users Profile Print this message


Hiltrud Braeuer

Posts: 8
Joined: 30-Oct-2003

Our experiences match Amy's. We stopped the partitionings in DOORS 5.2 after many tries and loss of working time.

Now we have entered the "new world", that is to say we migrated to DOORS 7.0 SP1.
Has anybody already done some partitioning with this version?
What are your findings?

Curious,
Hiltrud
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 1 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 1 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.