How to avoid deleting boundary elements you cant 'see'

[ArchBeast]

boundary elements do not appear in the project browser we are told because they are 'diagrams-only' elements. However we are finding that listing boundaries by an sql report reveals they have both Diagram_ID and Package_ID.

I'd like to be clear how this works so that if I delete a package or a diagram I don't inadvertently delete boundaries that are children of those diagrams or packages.

Any help would be appreciated.

[qwerty]

EA does take care. Only if a boundary is no longer related to a diagram it will be deleted. If you delete a package with a used boundary, the boundary will be moved. A bit unfortunate this hidden element feature. Has been discussed here, but will likely not change.

q.

[Uffe]

I have never quite been able to work out what t_object.Diagram_ID is for, since the presence of an element (t_object row) in a diagram (t_diagram row) is indicated by a row in t_diagramobjects.

But t_object.Package_ID is, to my knowledge, reliable: it specifies which package the element (hidden or otherwise) belongs to.

Boundaries and other diagram-only objects follow the lifecycle of the diagram they're in: it gets deleted, they get deleted. If you delete a package, all diagrams it contains get deleted along with any diagram-only objects in them. Pretty straightforward.

Where you may end up with a problem is if you copy a diagram-only object and paste it into other diagrams. You will quickly lose track of which one's the original, and so deleting that diagram will delete all the references.

The way around this is to always paste diagram-only objects as new: this creates a new row in t_object, not just in t_diagramobjects.

HTH,


/Uffe

[qwerty]

Uffe, the boundary is treated safe be EA (hear, hear!). Simple test:

• create a package with a diagram that has a boundary.
• Move the diagram to another package.
• Delete the package.
• The boundary is still there.

I guess that when you move a diagram to a new package, EA also moves the contained invisible elements like boundaries.

q.

[Geert Bellekens]

I have never quite been able to work out what t_object.Diagram_ID is for, since the presence of an element (t_object row) in a diagram (t_diagram row) is indicated by a row in t_diagramobjects.

It seems that the t_object_diagram_ID sometimes indicates diagram on which the element was created, but it if far from complete, so not to be relied on.
From the 20.000 rows in t_object there are only 77 that have an Diagram_ID that points to a diagram.

I have yet to figure out why these 77 objects have a diagram_ID and all the others don't.

Geert

[ArchBeast]

Many thanks for these replies, they have helped me a lot.

One thing though, I am seeing that I have orphaned boundary objects; they show up in sql search results, but are not in any diagram.
I'm nor clear how these are ending up orphaned and I am not clear how to remove them from the model, other than to write a script.

[qwerty]

I simply would not care much. Most likely a Project Integrity Check will clear them.

q.

[Paolo F Cantoni]

Many thanks for these replies, they have helped me a lot.

One thing though, I am seeing that I have orphaned boundary objects; they show up in sql search results, but are not in any diagram.
I'm nor clear how these are ending up orphaned and I am not clear how to remove them from the model, other than to write a script.

One way to do it is to remove the boundary from the diagram and then purge the diagram.  The boundary will then not be on any diagram and since you can't find them in the browser....

The integrity checker may find and delete them (since it can't display them under _Recovered_._objects_), but "Orphaned Element" these days (correctly) means an element whose package no longer exists...  (Ask me how I know...  )

HTH,
Paolo