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: v5.2 to v7.0
Topic Summary:
Created On: 18-Mar-2004 16:28
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.
 18-Mar-2004 16:28
User is offline View Users Profile Print this message


arlene lyle

Posts: 16
Joined: 18-Oct-2002

Hi

Can you import a v5.2 partition into a v7.0 database? and can you import a v7.0 partition into a v5.2 data base? If not is there a current workaround for transferring data between the two different versions?

Thanks

A
Report this to a Moderator Report this to a Moderator
 18-Mar-2004 18:24
User is offline View Users Profile Print this message


Michael Sutherland

Posts: 248
Joined: 13-Sep-2002

Arlene,

You can archive from a DOORS v5.2 database, and restore in a DOORS v7.0 database. Partitions are different than archives. Do you really need to use partitions, or will archives suffice?



-------------------------
Michael Sutherland
michael@galactic-solutions.com
http://galactic-solutions.com
Report this to a Moderator Report this to a Moderator
 18-Mar-2004 18:58
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

You can never go backwards in versions: 7to6, 6to5, nor 5to4. I don't think you can easily restore v4 in a higher version, but you should have no difficulty from 5to6, 5to7, and 6to7.

Partitions should behive likewise but you can never go back: if a v5 DB creates a partition to a v7 DB its effectively read-only since it cannot be returned.

I predict there will never be a utility to allow backwards restoring.

- Louie
Report this to a Moderator Report this to a Moderator
 30-Mar-2004 08:12
User is offline View Users Profile Print this message


arlene lyle

Posts: 16
Joined: 18-Oct-2002

If I archive the module will everything be archived? I only want a certain view or attributes to be archived. Is this possible?

As an alternative. I am thinking of creating a csv file which can then be imported into the version 7 module. I am concerned however about updates. If I send an updated spreadsheet can DOORS import this without deleting the previous objects? i.e. will it update accordingly?

Thanks,

a
Report this to a Moderator Report this to a Moderator
 30-Mar-2004 15:58
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

You cannot choose what to archive in the module; but No, it doesn't archive everything:

[1] Links are not archive. perhaps you should "capture5.dxl" to capture the link information before archiving.

[2] Module and Object specific access rights are set to Inherited. Thus, you lose all your shared-sections. This is actually a GOOD feature; see [3] below.

[3] View, AttrDef, AttrVal, and AttrType specific access rights are NOT set to inherited. This is a disaster since if you give "Joe" sole access to say "Object Text", its VERY likely that nobody but the "Administrator" will be able to edit Object Text when its restored. This is because the access records doesn't remember "Joe" it remembers user "248". When restored, user/group 248 in the restored DB will have sole access; and if there is no such user than nobody will. These access records should be manually cleared. I do this by staging the archive in a temporary local DB and log in as the Administrator.

And if you want to restrict what the customer gets consider the following procedure (gets no history nor baselines nor deleted objects):

[] Baseline the module; perhaps as "2.3"
[] Archive the module.
[] Logon to a local DB (perhaps on your C) as "Administrator".
[] Restore the module.
[] See [3] above
[] Purge all deleted objects.
[] Delete whatever Attributes you want to hide.
[] Baseline again; perhaps using suffix "a" or "ToTheCustomer": 2.3(a).
[] Delete all baselines (these last two erases ALL history).
[] Archive the module.
[] Send it to the customer.
[] Store the archive on a CD; purge the temp module.

Using a spread-sheet to update a module works so long as Objects are not deleted in the module.

[] Create a view featuring o AbsoluteNumber o Object Number o Object Heading
o Object Text o Attribute "Deleted" o Whatever other attributes (Rationale?)
[] Export this view to Spreadsheet CSV.
[] Lock down the module to "R" only.
[] Let the DOORS averse folks edit the spread-sheet.
o If they want to add a requirement:
o Add an object in the correct position in the Module.
o Note its AbsNo
o Add a line to the SpreadSheet in the correct position using that AbsNo
o If they want to delete an object; make "Deleted" true
o They cannot change attribute values not in the SpreadSheet: do NOT add columns.
o If they want to MOVE an object they can only take note of it.
o You cannot preserve OLE nor rich text markup.
[] Import the SpreadSheet CSV, using AbsNo as the "Key".
[] Find Objects marked as "Deleted" and delete them.
[] Move objects as desired.
[] Either UnLockDown the module or export it again.

I really don't know what happens if you add rows the the spread sheet that either have no AbsNo or are for AbsNos that do not exist in the module. Objects that are NOT represented with AbsNos in the spread sheet are NOT affected when you Import it.

- Louie
Report this to a Moderator Report this to a Moderator
 30-Mar-2004 16:18
User is offline View Users Profile Print this message


Pieter DE WAARD

Posts: 73
Joined: 11-Jul-2003

We work in a community with lots of "DOORS-averse folks". With reference to the last part of Louie's reply, my experience with excel regarding the addition of new lines without ID (object did not exist before) is as follows:
- If I leave AbsNo empty, and I use the option Update Existing Objects in Import Spreadsheet, it will update all changed objects, BUT introduce only ONE new object, where the the contents of this new object reflects that of the last new one found. In fact, the importer considers the empty AbsNo cells as the same ID.
- If I then fill in arbitrary integer values in the empty AbsNo cells for the new lines (condition: they may not exist in the DOORS module, so I start at a high number, incrementing by 1 for each new line), the import (same Update Existing objects option) add new lines to the module, with the AbsNo allocated by DOORS (the values I entered are disregarded, but nevertheless recognised by DOORS as new lines). BUT HERE IS THE SURPRISE (to me anyway): If the Excel file structure corresponds (ito order of objects) to the DOORS module (it was used to generate the Excel file in the first place), the new objects are added in the correct location in the module, and not at the bottom as I expected. Except in cases where the new line needs to be the first child of an existing object. In this case, DOORS puts it at the higher level, which then have to be corrected manually afterwards.

- Pieter

-------------------------
Pieter de Waard
www.nhindustries.com

Edited: 31-Mar-2004 at 15:20 by Pieter DE WAARD
Report this to a Moderator Report this to a Moderator
 21-Apr-2004 23:52
User is offline View Users Profile Print this message


Paul Miller

Posts: 376
Joined: 2-Oct-2002

I have a possible alternative,

When it comes to "santising" one or more modules before shipping to a customer or sub-contractor, I create a partition that contains the target set of modules (one or more) and use the partition definition features to determine which attributes and views are included. Partitioned modules do not include previous baselines or any other history information. All access rights are reset according to your partition definition.

The partition is then exported and the resulting partition file imported into a temporary project area (Can be on the same DB). The contents of the imported partition can then be worked on further if necesary, and then archived as a whole or the individual modules archived one by one.

As the partition will never be rejoined back to it's source, I use the "Recover" partition function to remove the partition locks on the original source modules.

Once finished with the partition residing in the temporary project area, you can remove it by using the "Return" function. The return partition file can then be destroyed.


-------------------------
Paul Miller
Specification Practices Specialist,
EuroCyber,
Melbourne, Australia.
Mobile: +61 (0)418 135 103
Web Site: http://www.eurocyber.biz
E-mail: miller@eurocyber.biz">pmiller@eurocyber.biz
Report this to a Moderator Report this to a Moderator
 22-Apr-2004 10:52
User is offline View Users Profile Print this message


Peter Seager

Posts: 32
Joined: 10-Feb-2003

The other advantage of using a partition is that access rights can be controlled. We were having trouble with access rights when an archive was restored to a foreign database and a module was not set to inherit access rights.
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 0 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 0 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.