Deleting Content Links Directly from the Database

[BenPerry]

Windchill Experts,

All too often I would like to delete something out of Windchill only to find out it has associations to other objects.  For this discussion, I only want to focus on the Content link between WTPart and EPMDocument.  I believe it is stored in EPMDESCRIBELINK table.  Think of this scenario:  "User creates a drawing, associates to WTPart, later descides not to use drawing (or use a different drawing) and it gets disassociated."  However, in this scenario, the EPMDocument (drawing) that we want to delete has links to old iterations of WTParts.  Thus we can't just delete the drawing.

I believe that there is not much risk in modifying the database to directly remove these rows from the EPMDESCRIBELINK table.  That will essentially delete the Content links.  You just have to be careful and know what you're doing.  I would not do the same for Owner links (it is stored in a different table in the database anyway).

What do you all think about this practice - removing the rows from the EPMDESCRIBELINK table in order to delete out Content links on objects that are otherwise not really editable through the UI?

For reference, I have also discovered a very handy WinDU tool in 10.2 M030.  I'm not sure when it first showed up.  It is called "Locate References".  You can enter an ID value of an object and it will search the entire DB for that ID value.  I entered the IDA2A2 of the A.2 version of a WTPart that had a Content link I wanted to delete.  The IDA2A2 value of that version of the WTPart was referenced in these tables:

1 found in BASELINEMEMBER.IDA3B5

1 found in CHANGERECORD2.IDA3B5

1 found in DERIVEDIMAGE.IDA3THEREPRESENTABLEREFERENC

1 found in EPMBUILDHISTORY.IDA3B5

1 found in EPMDESCRIBELINK.IDA3A5

1 found in EPMUPDATECOUNTER.IDA3A3

1 found in ESITARGETASSIGNMENTLINK.IDA3A5

3 found in HOLDERTOCONTENT.IDA3A5

12 found in STRINGVALUE.IDA3A4

1 found in WTPART.IDA2A2

1 found in WTPART.IDA3C2ITERATIONINFO

1 found in WTPART.IDA3E2ITERATIONINFO

After getting that picture of where the A.2 version of the WTPart was referenced, I did the same search for the IDA2A2 of the EPMDESCRIBELINK.  Then I was able to see that that specific Content link is only referenced in the EPMDESCRIBLINK table.  So deleting that row (and thus the Content link) from the database won't have an effect on anything else.  Nothing else references this Content link.

1 found in EPMDESCRIBELINK.IDA2A2

Let me know your thoughts.

[BenPerry]

No response from anyone on this?  That is interesting.  I thought I might get some questions asked of this process.  Or perhaps someone would caution me of something that I haven't thought about?

Has anyone played around with deleting rows from EPMDESCRIBELINK in the past to get around the inability to delete something?

[ericstarkman]

In a very specific use case, one of my customers is deleting it programmatically - i.e.  PersistenceHelper.manager.delete(theEPMDescribeLink) and has suffered no side effects.  As far as I can tell, that API call has the net effect of simply deleting the corresponding record from EPMDESCRIBELINK, and appears to have no effect on the objects on either end.

As you know, non-Content links are more complicated - not only are they a different object type & a different table, there is also a build history object / table, plus one must consider the impact on 'built' structures.

That said, I doubt anybody outside of TS is going to go out on a limb and tell you it's OK to ever make a direct database update.  But in the scheme of direct database updates, this one seems relatively low risk.