By eliminating the 1.3, it should relink to 1.2. As long as 1.x is still released or whatever your final state might be, the iteration is just showing the individual steps everytime it was modified for even the most minimal change. The "1" is the official release and the .x are the baby steps/modifications made to get it to the final state. Once it is released, the baby steps are insignificant. Once an item is released and you find the file is bad or another minor attribute issue, you must iterate to correct and you don't want the previous iteration left in the system, you should be able to delete.
Some of the cases we are running into are parts in the system that are incorrect and need to get out of the database. Once I correct the part it iterates and unless you delete the iteration that had the "bad" part you can not delete out of the database.
yes, you can delete the iteration but only if a new revision has not been created. I am asking for the ability to delete a previous iteration to a previous revision.
I would agree that is the normal but there are times when you need to do it. Unfortunately, we do not have the PURGE function in our area, however, we have a requirement for that capability.
In some of our cases, the latest iteration is incorrect so when you correct it, it makes a new iteration but again, it wont let you delete the earlier iteration when a new REVISION is already in place and that is where my concern is.
In Windchill today you have two options, delete and purge.
Delete
Moves from the most recent version backwards.
Cannot skip versions. Must delete the latest.
Can completely eliminate entire revisions.
Purge
Moves from the oldest iteration (of each revision) forward.
Cannot delete the latest iteration at each revision. (One will always be left)
Cannot delete an entire revision. (All revisions will remain.)
I have no idea if either one actually does any re-linking. I seriously doubt it. Rather, when some other part of Windchill is looking for a particular iteration, if that iteration is no longer available it will simply revert to the latest available.
If there's something wrong, that's what the revise is for.
However, even if a company doesn't subscribe to 'any revision is a revision' -- which is a huge mistake IMO -- simply set the old 1.x to a life cycle state that nobody (except admins) can see. That effectively "deletes" it as in it is no longer available for anything. This gets around a host of issues like the 'Referential Integrity Violation has occurred. Unable to delete file' error or the linking being discussed.
The purge utility does not work if there are build rules for EPMDocument to WTPart associations, even if you tell it to purge both the WTPart and the linked EPMDocuments. You can delete them both using the collector, but only from the latest version back which is not usually desirable.
Our most common use case for needing to remove an old iteration of something is to be able to delete an unwanted object that has a relationship to only that specific (and not technically required) iteration. The all too familiar “Referential Integrity Violation” prevents this with current technology and you are stuck with the unwanted linked object.
I thought PDM already had this functionality. If you go into the Delete function on something you see All Iterations Of This Rev, All Revisions, Latest Iteration as the options.
If you're talking about deleting a specific older iteration of a file with newer iterations available...isn't that a design record that by many industry standards you are never supposed to delete?
Personally I don’t see deleting a specific iteration as being any different than deleting the latest iteration. As long as the iteration numbers don’t re-sequence there is visibility of the removal, if companies need to prevent it being used then that is easily done using access control rules. The purge and archive toolset can already remove old iterations, but not if they have build rules (cad associations stronger than content) to another object.
The easiest to understand use case for this would be to imagine someone performs a save as operation on an assembly, they create an entirely new WTPart structure and corresponding CAD Document structure. During the save as operation they forget to mark one component as re-use, so A.1 contains a duplicate WTPart and CAD Document. Realising their mistake they iterate both to replace the duplicate components with the one they should have re-used. So A.2 no longer uses the duplicate component, but they cannot delete their duplicate component because it is used by iteration A.1 of the assembly. The A.1 iteration of the assembly objects was never released, and is not required, but cannot be removed/purged. The “Referential Integrity Violation” will prevent it and even tell you the iteration of the object that is preventing the delete.
Ideally the failed delete attempt should load the event manager and give an option to remove/purge the specific iterations, from there normal access control rules would control things just fine. If that is not feasible for whatever reason, then the purge and archive tool should be able to work when both “ends” of a build rule are being purged. Clearly both options would be ideal.
This problem has arisen in a situation where a model was incorrectly associated to a WTPart. I want to delete the model but I cannot unless I delete the associated WTPart. I can break the association and that creates a new iteration of the WTPart. I would like to delete the model and the proper iteration of the WTPart to remove this information from the database. I remember this as a function in Intralink that on occasion we deleted corrupted iterations.
I would like another option box that reads Delete only the iterations included in the table.
Thank you for the idea and conversation on this topic. The idea is interesting and we could see the benefit. However, given the team’s strategic priorities, we are unlikely to prioritize the implementation in the next development cycles. Should this change, we will bring this idea back.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
