![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Duplicate Objects including IDs Topic Summary: Module Curruption Created On: 30-Sep-2007 19:52 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Anyone come across the situation of DOORS creating duplicated objects, including IDs? This manifested itself when several users were updating the module in Shareable edit.
We're using DOORS 8.1, client have patch 6 embodied. Ewen Miller QinetiQ |
|
![]() |
|
![]() |
|
I have also seen this.
In my case the duplicate obejcts were created when using move() to move objects between lockable sections while in exclusive edit mode. Telelogic told me that this was fixed in DOORS 8.0. Sounds like you've discovered another bug. ------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
Tony/Ewen,
When this happens, is the module officially corrupt? Is this a big deal as far as a data integrity standpoint? In other words, if I just go in and fix the problem (delete the duped ID, then create a new object), is the module ok? I'm just curious in case anyone else runs into this. Thanks, Kevin ------------------------- Kevin Murphy http://www.baselinesinc.com The Requirements Management Experts |
|
![]() |
|
![]() |
|
In 2002, we had some similar problems under DOORS 4.1. It seems as an synchronize problem from client-side. The corresponding database file (aka absno.dt?) should be corrupted.
I dont think, that the whole module is corrupt. Perhaps it is possible to restore an archive (with non-damaged module) or you may send your (zipped) database files (from filesystem) of this module to Telelogic for correction. ------------------------- Dirk Plaschke |
|
![]() |
|
![]() |
|
Hi Kevin.
Telelogic have produced patch 8 for DOORS 8.1 which has some sort of utility which prevents the problem from occurring and sorts out history corruption issues. When I say corruptions, I mean it "restores"the object history to a previous state. The objects with duplicate IDs are uncmmanded copies of the original so can be safely deleted. Also we found that if the affected module was baselined, you could no longer open it - the module's associated *.dtc file had vanished from the file system. The fix for this is to stop the doors service, find the*.dtb file and rename it *.dtc, and restart the DOORS service. Telelogic tell me that DOORS 8.2 does not have this issue. |
|
![]() |
|
![]() |
|
Ewen,
This is great information to have! Thanks for sharing this. These types of issues are just no fun to deal with and there's not always a lot of info outside of Telelogic on how to go about fixing a weird problem like this. ------------------------- Kevin Murphy http://www.baselinesinc.com The Requirements Management Experts |
|
![]() |
|
![]() |
|
We (General Dynamics Canada) have seen this issue occur recently with DOORS 8.2 (with latest patch), on more than one occasion. Duplicate IDs have appeared, and eventually the module goes into a corrupted state not allowing it to be opened with an error message "Section file could not be opened: index entry not found". Our only solution has been to restore the module from a backup, followed by module cloning. Our assumption is that the backup module may be corrupted, and the cloning may fix/circumvent the problem. We have not seen the problem reoccur in the cloned modules.
This seems to occur in edit-shareable mode modules, and is quite random. We are trying to identify the source of the problem. |
|
![]() |
|
![]() |
|
Received the following reply from Telelogic support:
"Our Product Development team has got back to us and informed that the issues you have observed is most likely because of the Shareable edit defects which were fixed in the last round of patches for DOORS clients 8.1.0.8, 7.1.15, and 8.2.0.2. However, installing these patches for the appropriate DOORS versions wouldn't fix these problems if they are already in the data. These will still need to be fixed; the patches prevent any further data from becoming broken. As you have now upgraded to DOORS 8.3 client this issue wouldn't be observed unless the issue already exists in the data used from an earlier version of DOORS. We suspect that the modules that are experiencing this issue were already affected in the earlier version of DOORS but have surfaced only now. Also, if all the clients in your DOORS DB are not DOORS 8.3 (i.e. if some clients are still using older versions of clients) you may still find this issue occurring in the DB. Hence, please make sure that all the clients in your network are upgraded to DOORS 8.3 as soon as possible. " We have manually recreated our corrupted modules (since they were corrupted in the backup databases), and are in the process of upgrading all clients to DOORS 8.3. Hopefully, this will be a non-issue as we move forward. |
|
![]() |
|
![]() |
|
This issue is still being seen by us in 8.2 (client & server). It is not only related to shareable edit.
We have no modules configured for shareable edit but are in a mixed citrix and local client environment. The problem is easily reproducable. Modules opened and edited using only citrix client or only local client are fine. Modules updated (not even concurrently) by citrix AND local client become corrupted (lost history information + wrong userid that made the changes + duplicate object id... id starts at 1 again). |
|
![]() |
|
![]() |
|
We use local clients and Citrix clients all the time, on many Programs, and have not seen any module corruption; although, we have not consciously looked for it as a result of a mixed environment.
You mention that the problem is easily reproducible. Can you outline a scenario that I would be able to follow to see if I can replicate the corruption? Finding a reproducible source of this problem is critical to all of our Programs. |
|
![]() |
|
![]() |
|
Joe, sorry it has taken some time to get back to you. This problem is coming at us all the time now. It appears to be some kind of problem with the 'copy object' function and client synchronisation. Here is how we reproduce corrupted history.
Setup: - Client 8.2.0.2 (Citrix) - Server 8.2 (Linux Red Hat) - Need 2 different userids + sessions to cooperate to (re)create the issue Notes: U1 = user 1 U2 = user 2 S1 = session 1 S2 = session 2 Steps to reproduce: 1. S1: U1 creates new formal module 2. S1: U1 inserts some new objects as a hierarchy (eg 1, 1.1, 1.1.1) into module 3. S1: U1 saves and exits module but does not exit DOORS 4. S2: U2 opens the module in exclusive edit 5. S2: U2 selects chapter 1 and copies the objects with hierarchy 6. S2: U2 inserts after 1 and saves 7. S2: U2 views history for all, looks ok 8. S1: U1 open module in read-only and looks at history for all... sees missing user data 9. S2: U2 closes module but does not exit DOORS 10. S1: U1 switches to exclusive edit mode 11. S1: U1 selects chapter 1 and copies the objects with hierarchy and pastes after chapter 2 and saves. 12. S2: U2 opens module read-only and looks at history for all... sees missing data and corrupted sessions numbers. Module history remains corrupt to all users even when both users have exited DOORS. Repeating this experiment with the same client 8.2.0.2 but installed locally on their laptop/desktop for both users results not in module history corruption but in duplicated absolute object ids (restarts absolute number at 1) after using the 'copy' function. If one of the objects with duplicated ids is then deleted and a module purge is made, the next object inserted still receives an absolute number of 1, the next 2, etc., ie. the 'last used absolute number' stored in the database for that module appears to be corrupted. The only method we have to recover is to create a new module, copy attribs from the old module, copy views from the old module, copy objects from the old module, recreate links. We never saw this problem on 7.1 or 8.1 only on 8.2. |
|
![]() |
|
![]() |
|
Joe, by the way... Are you using an 8.3 client with an 8.2 server? Has this solved your problems?
Thanks. |
|
![]() |
|
![]() |
|
Adrian, I followed your steps and was not able to reproduce the problem. All worked as expected. We have the following setup
- Client 8.3.0.2 - Citrix - Server 8.1.0.0 (HP-UX) |
|
![]() |
|
![]() |
|
Forgot to mention that we have not seen any corruption issues since we upgraded all of our clients to 8.3. We have kept our server at 8.1 to allow for data exchange between our various subcontractors who are unable to upgrade their servers at this time.
|
|
![]() |
Telelogic DOORS
» Defect/Issue Tracking
»
Duplicate Objects including IDs
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.