cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

What is your best practise for the handling of objects which have to be deleted?

Highlighted
Level 8

What is your best practise for the handling of objects which have to be deleted?

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?

10 REPLIES

Re: What is your best practise for the handling of objects which have to be deleted?

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.

Re: What is your best practise for the handling of objects which have to be deleted?

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.

Re: What is your best practise for the handling of objects which have to be deleted?

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.

Re: What is your best practise for the handling of objects which have to be deleted?

Ok, we thought the "Purge Manager" can run regular tasks to delete objekts in specified folders completely.

Re: What is your best practise for the handling of objects which have to be deleted?

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.

Re: What is your best practise for the handling of objects which have to be deleted?

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.

Re: What is your best practise for the handling of objects which have to be deleted?

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.

Re: What is your best practise for the handling of objects which have to be deleted?

The non-latest parent object will also be deleted (purged) and thereby maintaining the integrity of the system

Re: What is your best practise for the handling of objects which have to be deleted?

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.