Package / element GUID mismatch

[Uffe]

Hello all,


A client, who's on 11.1, is having problems with a centralized reference model which gets distributed through the reusable asset service.

Going through it I noticed something odd: there is a mismatch between t_package.ea_guid and t_object.ea_guid for all the packages in this model. The locking mechanism has also gone haywire, and I assume this is the cause.

If I look in the project browser, nothing is locked.
If I look in the Manage Locks dialog, all the schizoid packages are locked.
If I drag one of the packages onto a diagram, I can "Release User Lock" in the context menu.

These issues persist when distributing the model to other projects through RAS.
The project integrity check says everything's fine.

What is the correct way forward here?

I can hack the database to make the GUIDs match -- but which one should take precedence?
Where, in addition to t_package.ea_guid / t_object.ea_guid, do I need to hack?

Or is there a gentler, kinder way?

Thanks,


/Uffe

[Geert Bellekens]

According to some comments from a Sparxian a while ago you shouldn't rely on the fact that the guid's of the t_package and t_object are the same, but instead use the relation stored in t_object.pdata1.

But in all models I've worked with the guid's always matched (I've not used the RAS yet anywhere).

Given the fact that your locking mechanism seems to be broken I guess a Sparx developer relied on the GUID match anyway
That's the danger of providing an easy mechanism that works in almost al cases.

I admit that I use the GUID match often myself, although I know I'm not supposed to. I'll be careful with that whenever I start using RAS somewhere.

Geert

[Paolo F Cantoni]

Well, the Integrity Checker resets the GUIDs if they are different, so to argue that one shouldn't use the ea_guid is somewhat specious - since in a properly formed reposiotry that are the same.  But then that's EA all over - self-inconsistent...

I, like Geert, recall a Sparxian saying one shouldn't rely on ea_guid matching.

Paolo

[Eve]

Well, the Integrity Checker resets the GUIDs if they are different ...

I don't think it has ever done this, and the OP said that it didn't.

[Paolo F Cantoni]

Well, the Integrity Checker resets the GUIDs if they are different ...

I don't think it has ever done this, and the OP said that it didn't.

My Bad!  I think I got confused with mismatched Names (not GUIDs) for Element and Package.  The integrity checker will certainly fix them up.

Paolo