854: Association Classes incorrectly imported

[Paolo F Cantoni]

If the Association Class is NOT in the importing XMI package, then things will not work properly.  If the Association Class is already present in the repository, then EA will attempt to create a duplicate GUID which results in an extra copy of the Association (for which this Class is the Association Class)

If the Association Class is NOT present in the repository, then EA will create an Empty Association Class.

Steps:
Create an Association Class
Export the package, import - all is fine
Move Association Class to a package that is NOT exported with the Association and its end-points.
Export the package, import - observe erroneous behaviour

The problem appears to be that the PDATA1 column of t_connector (which contains the Object_ID of the AssociationClass - as documented in connectorType Macro) is mishandled on import...

This severly inhibits transfer of XMIs between repositories.

Reported (and sample supplied),
Paolo

[edit]Confirmed with build 855 (v8.0 official release)[/edit]

[Paolo F Cantoni]

Because of this bug, I've had a look at the repository that was problematic.

It's been around for a number of years (at least 5).

There are some t_connector Associations with PDATA1=0  I guess, by definition, these are corrupted?  I'll replace the 0 with Null.

Secondly, there's been discussion (from time to time) about how EA doesn't create anemic end-points for missing (vertexes of arcs) that are imported using XMI.  This forces us to import a series of packages twice (at least).  Well, it seems EA IS able to create anemic elements - it does so as part of this bug!

Thoughts?
Paolo