revert module to old baseline

tskaletz - Wed Aug 31 05:16:53 EDT 2011
Thanks all for your help!

As a result I think there is currently no perfect solution.

• To use a backup seems the most complete and most secure solution. But it needs much user discipline.
• Next to this comes the copy of a baseline into a new module. This solution has just the drawback to loose the history.
• The most complicated and most dangerous way seems to manipulate the database. I think that this should be only used as a last effort to recue a module which was messed up.

ChrisAnnal - Tue Aug 23 09:22:34 EDT 2011
I'm not sure how many baselines you have, but I had a similar situation in a project that was just getting started, and only had one previous baseline. Here's what we did, since the changes made in the previous baseline were not something we desparately needed to keep track of:

1. Open the module and choose File -> Baseline -> Copy
2. The above will create a copy of a selected baseline of the current module - in your case you want the previous baseline, so select that one. (The default is "All Information", suggest leaving that selected).
3. The "new" module is a copy of the baseline you wanted to revert to, but you will need to link your objects in this new module all over again. (This wasn't a big deal in our case, since we used a "LinkByKey" approach and only had to repeat that step for the new copy of the baseline).

You might try the above as a possible solution. Hope this helps.

Chris Annal
SW Test Engineer / DOORS Database Administrator
Saab Sensis Corporation, East Syracuse, New York
chrisa@saabsensis.com

Chris Annal
SW Test Engineer / DOORS Database Administrator
Saab Sensis Corporation, East Syracuse, New York
chrisa@saabsensis.com

RianWouters - Mon Sep 05 09:32:50 EDT 2011
AFAIKS, File -> Baseline -> Copy does not copy the original Object id.

Anyone has a solution for that?

Mathias Mamsch - Tue Sep 06 03:20:22 EDT 2011
In the Telelogic Kitchen Tools there is a script, that will copy a module with absolute numbers intact. It will create objects in the right order (making dummy objects as necessary to fill the gaps), purge away the dummy objects, and then restructure the objects to have the correct hierarchy. The script is called "duplicate.dxl" and is in the Modules folder. To get a copy of the kitchen tools look at this post:

https://www.ibm.com/developerworks/forums/thread.jspa?messageID=14484868&#14484868

Regards, Mathias

RianWouters - Wed Sep 07 11:53:23 EDT 2011
Thanks Mathias.

Tried it, but still have several problems using it on DOORS 9.3:

• #pragma isn't recognized; removing the # helps of course
• I get errors saying the "Absolute Number" attribute cannot be read
• I get errors saying that a module with the same name exists; closing and opening the module seems to help

RianWouters - Wed Sep 07 11:59:40 EDT 2011
I finally arrived at:

...

<C:\Program Files\IBM\Rational\DOORS\9.3/lib/dxl/addins/kitchen/Modules/duplicate.dxl:211>
-R-W- DXL: <C:\Program Files\IBM\Rational\DOORS\9.3/lib/dxl/addins/kitchen/Modules/duplicate.dxl:60> no access to read attribute 'Absolute Number'
Backtrace:
<C:\Program Files\IBM\Rational\DOORS\9.3/lib/dxl/addins/kitchen/Modules/duplicate.dxl:211>
-R-E- DXL: <C:\Program Files\IBM\Rational\DOORS\9.3/lib/dxl/addins/kitchen/Modules/duplicate.dxl:80> An unexpected error has occurred: invalid absolute number

Backtrace:
<C:\Program Files\IBM\Rational\DOORS\9.3/lib/dxl/addins/kitchen/Modules/duplicate.dxl:211>
-R-F- DXL: <C:\Program Files\IBM\Rational\DOORS\9.3/lib/dxl/addins/kitchen/Modules/duplicate.dxl:80> internal error, please submit a bug report
Backtrace:
<C:\Program Files\IBM\Rational\DOORS\9.3/lib/dxl/addins/kitchen/Modules/duplicate.dxl:211>
-I- DXL: execution halted

Any suggestions?

llandale - Wed Sep 07 14:42:48 EDT 2011

I cannot download the latest Kitchen but have one that I've labeled for v7.1. It appears this is the offending code:

while ( newAbsNum < oldAbsNum )
        {
            Object lastObj = newObj
 
            newObj = create after lastObj
 
            hardDelete(lastObj)
            flushDeletions()
 
            newAbsNum = newObj."Absolute Number"
        }

You can find the file and edit it and find the offending code for you.

I'm guessing there is a timing problem with the hardDelete and the flush vis-a-vis the lastObj and newObj Handles, and that the newObj Handle is still pointing towards the recently purged lastObj location, which is corrupted but not erased. You should thus get some sort of "bad object handle" error but instead get what you got.

Its like pushing the open-door button and then charging into the room. Usually the door has had a chance to open completely (purge the object) but sometimes not.

If it were me I would try these in order:
1 move the flushDeletions AFTER the loop.
2 insert a "sleep_(100)" command to improve the timing. Play with the number, which is milli-seconds, 100 being 1/10th of a second and may not be long enough.
3 Get help from Mathias

• Louie

RianWouters - Thu Sep 08 04:47:06 EDT 2011
I downloaded the newest AFAIK at http://rapidshare.com/files/405757700/kitchen_tools.zip.html
Its labeled "Kitchen Tools for customizing DOORS with DXL V6"

The offending code is
for oldObj in all oldMod do
{
int id = oldObj."Absolute Number"
put(oldObjList, id, oldObj)
numOldObjs++
}

It appears I don't have read access to the "Absolute Number" of deleted objects.

RianWouters - Thu Sep 08 09:30:46 EDT 2011
I managed to work around the read access issue by using instead:

int absolutenumber(Object o) {
Module m = module(o)
string prefix = m."Prefix"
string id = (identifier(o))length(prefix):
return intOf(id)
}

Now I run into several new issues:

• Popups saying "Cannot create link: A linkset pairing restriction prevents the creation of links from MY -> Copy of MX"

• Popups saying "Cannot create link: No access to source object"

• Many errors of the form:

RianWouters - Thu Sep 08 09:30:46 EDT 2011
I managed to work around the read access issue by using instead:

int absolutenumber(Object o) {
Module m = module(o)
string prefix = m."Prefix"
string id = (identifier(o))length(prefix):
return intOf(id)
}

Now I run into several new issues:

• Popups saying "Cannot create link: A linkset pairing restriction prevents the creation of links from MY -> Copy of MX"

• Popups saying "Cannot create link: No access to source object"

• Many errors of the form:

Mathias Mamsch - Sat Sep 10 18:33:28 EDT 2011
I do not get the code that you fixed. Why the heckles would anyone create an int absolutenumber(Object) function? From the error you are getting it really seems, that the kitchen tools code is slowly getting outdated. It seems DOORS 9 might have changed the "Picture" attribute to not even be readable OR some script at your company did. It would be a bad idea to duplicate a module without having complete access. In the other case you really need to do some digging, like trying to read the "Picture" attribute with the same code that produces the error and see what the problem is. You should add some error checking to the code. The picture attribute can be excluded since pictures are handled separately anyway. Or I am not even sure if pictures are handled correctly. You need to check for yourself. I only know that we used that script as a base for implementing a "branch modules" script and as far as I remember it worked pretty good, although it needed some tweaking.

Regards, Mathias

RianWouters - Mon Sep 12 11:43:01 EDT 2011
I turned out my baseline contained some Read locked data. That's why I could not read the Absolute Number.

Interesting (but useless in this case :-)) to know that the Absolute Number can still be calculated from the identifier.
But I got around it now using canRead(o)

Still working my way through the issues.
It turned out I had some obsolete linksets to deleted modules that the could not be removed easily.

Next problem is this one:
-R-E- DXL: <C:\Program Files\IBM\Rational\DOORS\9.3/lib/dxl/addins/kitchen/Modules/duplicate.dxl:182> A hierarchy to be converted into a table can only be 3 levels deep (table, rows, cells)

It took me a while to find out that the lexical ordering of the objects does not work correctly for deleted objects.
That's why the level structure is broken.
Not sure if this is a bug in the original script or caused by a V9.3 change.

RianWouters - Mon Sep 12 12:13:26 EDT 2011
The problem seems to be that '-' comes before '.' while DOORS puts it the other way around.
For example, the original module has

26.15.6
26.15.6.0-1
26.15.6.0-2
...
26.15.6-1
26.15.6-2

this becomes

26.15.6
26.15.6-1
26.15.6-2
26.15.6.0-1
26.15.6.0-2
...

tskaletz - Wed Aug 31 05:16:53 EDT 2011
Thanks all for your help!

As a result I think there is currently no perfect solution.

• To use a backup seems the most complete and most secure solution. But it needs much user discipline.
• Next to this comes the copy of a baseline into a new module. This solution has just the drawback to loose the history.
• The most complicated and most dangerous way seems to manipulate the database. I think that this should be only used as a last effort to recue a module which was messed up.

kbmurphy - Mon Sep 12 19:51:48 EDT 2011
Although this discussion went down a very technical path and was worth having, I'd like to point out that my original response was correct. The answer I originally gave was no.

Also, OurGuest, making a backup of the entire database to do an experiment won't work if multiple modules/projects are being modified. Then you lose all of the work that was done between the time of the backup and the time you want to revert.

If people want to experiment with things, the solution is to give them access to a sandbox area and copy modules into it for them.

OurGuest - Tue Sep 13 08:05:41 EDT 2011
Kevin, It is only a figment of your imagination that I said to recover the entire database. If a company does prudent archiving of the database, they can recover portions that are critical.

But more important is what is your point – you want pat on the back for saying –no when someone was wanting help. If you do then here is an atta boy.

kbmurphy - Tue Sep 13 09:59:08 EDT 2011
OurGuest, you didn't say to recover the entire database, but you also didn't say to recover a portion of it either. And I think it's frankly very bad advice to lead people down the path of messing with the actual database files for something like this, prudent backup or not.

Thanks for the atta boy!

OurGuest - Tue Sep 13 10:45:02 EDT 2011
If my words were leading the user down a path of destructions -- that user really has no business having a logon id -- there is a certain point when you assume the user passed first grade and has seen a computer before.

llandale - Tue Sep 13 12:22:36 EDT 2011
Recovery is for disasters. If you have procedures that encourage folks to rely on recovery then you have a serious problem. Or actualy they have a serious problem.

I advise you not to let your customers know if you let your 1st grader manage their database. Maybe I'm just an old prude (and maybe not 'maybe') but I won't let my 6th grader, who types faster than I and can multi-task, even near my home computer let alone near production databases. (Digressing, I woulnd't let me near them either but I have no choice...)

If there's a convenient way to restore "part" of a database by all means let us know.

You can indeed purge a module and restore from a module archive built from a recent backup and then thus only lose perhaps two day's work on that module, but you have a significant difficulty re-establishing all the links for that module, expecially if those links have link attribute values.

You can indeed purge a project and restore that from an archive from backup, but again you have that nasty problem of re-establishing the links from outside the Project.

And you have the problem of re-establishing all the access rights and wizard layouts and attr-DXL and external links, bla bla bla.

• Louie

llandale - Tue Sep 13 12:22:36 EDT 2011
Recovery is for disasters. If you have procedures that encourage folks to rely on recovery then you have a serious problem. Or actualy they have a serious problem.

I advise you not to let your customers know if you let your 1st grader manage their database. Maybe I'm just an old prude (and maybe not 'maybe') but I won't let my 6th grader, who types faster than I and can multi-task, even near my home computer let alone near production databases. (Digressing, I woulnd't let me near them either but I have no choice...)

If there's a convenient way to restore "part" of a database by all means let us know.

You can indeed purge a module and restore from a module archive built from a recent backup and then thus only lose perhaps two day's work on that module, but you have a significant difficulty re-establishing all the links for that module, expecially if those links have link attribute values.

You can indeed purge a project and restore that from an archive from backup, but again you have that nasty problem of re-establishing the links from outside the Project.

And you have the problem of re-establishing all the access rights and wizard layouts and attr-DXL and external links, bla bla bla.

• Louie

SystemAdmin - Wed Sep 14 19:08:57 EDT 2011
Some courteous, sage and more importantly, entertaining advice here from Louie to which I concur.

SystemAdmin - Wed Sep 14 19:08:57 EDT 2011
Some courteous, sage and more importantly, entertaining advice here from Louie to which I concur.