Community Tip - When posting, your subject should be specific and summarize your question. Here are some additional tips on asking a great question. X
How do you handle objects in PDMLink which have to be deleted in the daily business?
The standard user can´t (and shouldn´t) delete those objekts
We thought about a folder in every content which is purged regulary.
Does somebody have experience with that or better solutions?
It is nearly impossible to delete something (purge or manually) from Windchill. Unlike Intralink 3.x, you cannot override "in use". If the object you want to delete is being referenced by anything, it will not allow you to delete it. About the only time we ever delete anything anymore is immediately after it was created. The longer something exists the more likely that something else will become dependent on it.
Oh, and I should add that purge is not capable of deleting all iterations of a particular revision. It will always leave at least one iteration at each revision. You cannot purge earlier revisions completely.
It helps to remember that "purge" moves from the past to the present (but always leaving the latest at each rev) and "delete" moves from the present to the past.
For instance:
A.0, A.1, A.2
B.1, B.2, B.3
C.1, C.2, C.3
Purge will can remove A.0, A.1, B.1, B.2, C.1, and C.2, but it cannot remove A.2, B.3, or C.3
Delete can remove any of them, but only in the order they were created. C.2 cannot be deleted unless C.3 is deleted first. Likewise, nothing in rev B can be deleted until all of C as been deleted.
Ok, we thought the "Purge Manager" can run regular tasks to delete objekts in specified folders completely.
I have a folder named 'Oblivion' where we move redundant CADdocuments to. I considered to have an small aid developed so users could do the move themselves, but it turns out that the need is very very low.
Regards, Hugo.
Besides the CADdocuments, we create and use WTParts and SUMAParts. So we have a higher need for the removal of redundant Objects. I guess we´ll use also such a folder and move the stored parts into a "trash library" where noone can see or use them anymore.
Our procedure to manage items not to be used is to rename, set state (void) and move to a special context.
However, we also purge these items later on whenever they no longer have a reference to the latest iterations of ther "parent" items.
However, we also purge these items later on whenever they no longer have a reference to the latest iterations of ther "parent" items.
How? Unless you delete the earlier version of the parent in which they were used you will never be able to purge/delete them, even if no longer referenced by the latest parent.
The non-latest parent object will also be deleted (purged) and thereby maintaining the integrity of the system
That only works if the previous version is at the same revision as the latest. If not, then there is no purging it.
A.2 -> reference to 'some part'
B.0 -> revised
B.1 -> updated to remove reference to 'some part'.
Now you want to delete 'some part'. Can't because A.2 still has a reference to it. Can't purge A.2 because it's the last iteration of the A revision. Now you're stuck. The only option is to put 'some part' somewhere not visible to others.
I imagine it is theoretically possible to go back a create a new version after A.2, but before B.0, but the way most systems are setup, once A.2 is released there is no changing it without a new revision.
try {
manually delete the object
}
catch (cannot delete object){
try {
delete all parent objects
catch (cannot delete parent objects){
move to a folder called 'obsolete objects'
}
}
you know, try to delete and if you can't, move it aside in a separate folder. We've never even tried to delete obsolete objects after e.g. a context purge.