Community Tip - You can Bookmark boards, posts or articles that you'd like to access again easily! X
We have a tremendous number of files that are obsolete or otherwise useless to us, and there doesn't seem to be any way to delete them in WindChill. We get all sorts of error messages, most of them stating that some sort of relationship exists. We know those relationships have been broken (family tables) yet we cannot delete anything. Most recently we got the following message:
wt.vc.VersionControlException cannot be cast to wt.epm.confilict.EPMNonOverrideableConflictException
This message makes absolutely no sense to anybody here and is obviously code for some sort of error that we cannot figure out. Is there ANYBODY out there who knows how to delete useless files?
Solved! Go to Solution.
To close this community thread on Windchill "wt.vc.VersionControlException cannot be cast to wt.epm.confilict.EPMNonOverrideableConflictException" error
Summary and list of references:
Bill
This is a good question. Deleting old versions, iterations of objects or totally deleting objects can be tricky (and it is most times) and not always possible. This "issue" (I quoted this because I don't think it's ctually an issue) is relevant to all PDM systems.
As you correctly noted, this is mainly because of relations between objects stored in Windchill. You can't delete an object while it has relateions to other objects in the system. If you "brake" the relations, in most cases your object gets iterated and, thus, while the latest iteration has no links/relations, previous iteration(s) still have.
E.g. if you have a part which references a document and you then remove the reference, you still won't be able to delete the document since part's previous iteration(s) has reference to the document. You can only delete the document if you delete it together with the part of if you delete part's non-latest iterations first. But in non-trivial cases like this, revisions, family tables, LCs/workflows etc comes into account, it's getting much more complex. But again, it's not about Windchill, it's about PDM in general.
Now the technical "tip" - the main tools to get rid of obsolete/useless data are "Purge" and "Delete non-latest iterations" and they do help in many cases. Have you tried the tools?
These tools DO NOT work for us at all. They are completely useless.
What I find amazing is that NOBODY from PTC can offer a SINGLE usefull solution to my problem. The only response I ever get is from other frustrated users of Pro/E out there.
WAKE UP PTC!!!!!!!!
WE NEED AN ANSWER.
Here is an example of family table data that will not purge. Notice the pro_version column, all the pro e files are at a - revision. You would think that this data would purge leaving the -.5 locating_ring.prt and it's instances, but it won't. Since ft_version has a different revision (- and A) the system won't purge because they are the latest on that revision. Not sure why the ft_version does not follow the pro_version. To get around this PTC had to provide a delete utility that lets us remove these items that fail on purge.
cadname | pro_version | doc_is_latest | ft_status | ft_id | ft_version |
locating_ring.prt | -..4 | 0 | gen(t) | 6503118 | -..1 |
zlocrindme6500.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6501.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6501ln.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6502.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6503.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6504.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6505ln.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6510.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6511.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6520.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6521.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6522.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6524.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6534.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6535.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6536.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6537.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6541.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6544.prt | -..4 | 0 | inst | 6503118 | -..1 |
zlocrindme6548.prt | -..1 | 0 | inst | 6503118 | -..1 |
locating_ring.prt | -..5 | 0 | gen(t) | 6503124 | A..1 |
zlocrindme6500.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6501.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6501ln.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6502.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6503.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6504.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6505ln.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6510.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6511.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6520.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6521.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6522.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6524.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6534.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6535.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6536.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6537.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6541.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6544.prt | -..5 | 0 | inst | 6503124 | A..1 |
zlocrindme6548.prt | -..2 | 0 | inst | 6503124 | A..1 |
Looks remarkably similar to the problems we're facing. We're constantly having issues trying to break apart family tables and deleting instances that we know are useless, yet there is no solution. All we get is a constant stream of error messages prompting us to first delete this, then delete that......none of it works.
Most of our problem family tables came from migrated data. The ft_version did not exist in Intralink 3.X. When we migrated the system assigned those values.
Find a family table that was migrated and one that was created new in PDM Link then run this query on them.
select
doc.idA2A2 doc_id
, doc.idA3masterReference doc_mas_id
, dm.CADName cadname
, (doc.versionIdA2versionInfo +
(case WHEN doc.oneOffVersionIdA2oneOffVersi is NULL then('.')
else doc.oneOffVersionIdA2oneOffVersi + '-'
end ) + '.' + doc.iterationIdA2iterationInfo ) ver
,doc.updateStampA2 last_mod_date
, doc.latestiterationInfo doc_isLatest
, doc.statecheckoutInfo doc_co_state
, (case doc.familyTableStatus
when 0 then ''
when 1 then 'inst'
when 2 then 'gen(t)'
when 3 then 'gen(m)'
else 'uknown'
end ) ft_status
, ci.idA3B5 ft_id
, (ft.versionIdA2versionInfo +
(case WHEN ft.oneOffVersionIdA2oneOffVersi is NULL then('.')
else ft.oneOffVersionIdA2oneOffVersi + '-'
end ) + '.' + ft.iterationIdA2iterationInfo ) ft_ver
, ft.idA3masterReference ft_mas_id
, ft.statecheckoutInfo ft_co_state
, vl.idA3B5 gen_id
, doc.createStampA2 doc_create_date
, ft.createStampA2 ft_create_date
, doc.idA3C2iterationInfo doc_predecessor
, dm.authoringApplication authoring_app
from
EPMDocument doc
left join EPMContainedIn ci on doc.idA2A2 = ci.idA3A5
left join EPMSepFamilyTable ft on ci.idA3B5 = ft.idA2A2
left join EPMVariantLink vl on doc.idA2A2 = vl.idA3A5
join EPMDocumentMaster dm on dm.idA2A2 = doc.idA3masterReference
left join EPMSepFamilyTableMaster ftm on ftm.idA2A2 = ft.idA3masterReference
where
(ftm.idA2A2 in (
select distinct ftt.idA3masterReference
from EPMDocument d
join EPMDocumentMaster dmm on dmm.idA2A2 = d.idA3masterReference
join EPMContainedIn cii on d.idA2A2 = cii.idA3A5
join EPMSepFamilyTable ftt on cii.idA3B5 = ftt.idA2A2
where dmm.CADName ='lp_bushing_w-step_hasco_metric.prt'
)
)
order
by ft_mas_id, ci.createStampA2, ft_id, cadname;
We had a huge issue purging family table objects. Ended up getting a delete utility from PTC.
We have an issue with deleting/purging in Windchill as well.
Kent, could you possibly share the delete utility?
Contact PTC for the utility. It is delivered in a temp patch format and they will have to ensure it will run with your production environment.
Joe,
I have tried all week to acquire this delete utility from PTC, and so far nobody knows what this patch is. Following is my correspondence with them:
Hi Bill,
I have rechecked this there is so such Patch or utility that PTC provides to allow deletion of unwanted files. Can you get the Customer name & the SPR number for which the person on PTC forum has mentioned that he had got the utility for.
Is it like that the User had got this utility from the Sales representative or something? In that case, from Tech support point I may not be able to assist you on this because we can only provide you official patches approved by R&D.
If you require any assistance for deleting the Instances which are removed from the Family table one-by-one I can create a new Case with WGM support to follow up with you on this.
Let me know if you have any questions.
Regards,
Email: - |
The PTC Call that handled this issue is 07664646. Temp patch info is below.
9.1-M0X0_WCTK_1.0 Windchill Toolkit [Seq 01]
May I make a suggestion? Open up the offending family table generic (make sure all objects are in your workspace), make a change to the generic that will cause all instances to need verification, verify all objects, and save the generic. This should create a new version of all objects at the same in version as the generic. Lastly, purge all non-latest to see if this helps.
Afterwards, lock down your family tables!
That's part of the problem, we don't see the option to "Delete all non-latest versions". The only options we get:
"Delete all iterations"
"Delete all revisions"
"Delete latest iteration" and
"Run action in the background"
As for purging, we've had no luck with that either. The purge manager tool fails to collect the data that we're searching for in commonspace.
The connections to objects are stored in the DB and can be removed bit by bit or through a series of SQL commands, though you will never have a PTC TS representative advocate for this kind of fix, as it is not "supported" (though definitely possible).
I've done similar types of deleting during loading projects and I think I could help you here, but before going deeper: is there a specific reason why you are looking to flat-out DELETE the objects instead of using life cycle states to denote obsolescence? Also, are we talking about a lot of objects (100s or 1,000s) or merely a handful?
Send me an e-mail at robert.sindelar@eccellent.com if you are interested and would like to discuss further.
Hi,
I have attached a method which I use to attempt to delete all versions/iterations of the objects. Having seen your problem I expect you have tried soemthing similar....
-Ste
Hi,
If I try to purge a few objects, I always get failed because of the "EPMBuildHistory link". Is it possible to delete this link or break it?
Doing a little grave digging to see if anyone else had asked this question as well.
We also have this issue. It's all too easy for a user to create a CAD Document with a Filename or Number that has a mistake in it and perform a CheckIn. They are human, and mistakes slip through. Then, the mistake is not caught until that object is linked to a parent assembly, and that assembly is a sub-assembly to other assemblies, and you have a nightmare on your hands.
The main cause for us is when a user performs a Save-As on an assembly and doesn't exclude all of the children that they should have. So a file somewhere in the CAD structure gets duplicated with a bogus name/filename/number and linked to the new assembly(ies) when it was actually supposed to be an existing component that would have been reused.
We can replace the mistake with the correct model and re-CheckIn, but as already described in this thread, the old iteration(s) are already linked to the mistake.
PTC really needs to implement the ability for the allmighty admin to be able to break this link and delete mistakes from the system and from the parental CAD structures, if and when the affected CAD structures are not the latest iterations (meaning the latest has a good structure, we're only breaking it on the old iterations).
What I did in a similar case is that, after making sure that my design assembly has no relationship with the files that I desire to remove from my exisitng workspace, I have backed up the design assembly into a local drive. Then imported it back with the setting "required" into a brand new workspace using Tools>Import to Workspace.
The opening menu gives you the option to set which components are "new" which are existing. You set them all to "Reuse" and it won't set the really really new one to "reuse". Now that you can import. It may ask you that it will get some files from commonspace go ahead and hit yes. Now in your brand new workspace you only have the design assembly and its dependents and no longer the files that you were going to delete. You can check in youir design assembly now. and Remove the old workspace if you no don't have anything in it still left not checked in.
ali
If you have already released a new revision of an item then you can not delete previous revisions including non-latest iterations, unless you delete the current revision. Also, when it comes to EPMdocuments you also need to remove the links in CREO.
To delete non-latest iterations you have to do that from within the document, click on the Actions tab and you should see Delete Non-latest iterations but again if a new revision has been created then you will not be able to delete the non-latest iteration for a previous revision.
Hi there,
Deleting files in Windchill can be picky, but it is by design given industry standards.
By ISO standards you aren't supposed to fully delete design data, it is design history that can be evidence in a court of law. So Windchill has certain locks in place that help protect this; if a version of a file is in use anywhere in a BOM structure extra locks get put on it. If you really need to delete something old you have to break every BOM link to it. If the files in question are the latest revisions of the files it isn't as difficult since you can delete the latest iterations of WT parts and CAD files, but if it is buried in the older historical versions Windchill also protects all older iterations of every file.
Because of the industry standards around this you should really look at why you need these files fully deleted, instead of perhaps hidden or even ignored. Deleting design history is never a good thing and can really bite you later.
Just to clarify, because a few people are referring to released objects, I am not talking about breaking links in released structures. Obviously that is a huge No-no.
What I'm referring to is when you create an assembly and accidentally duplicate a part inside it. But you check in that assembly to commonspace. Then, you replace that component with the correct one, and check in the assembly again.
Now, in this simple specific case, I can delete non-latest iteration of the assembly model and then delete the mistake component. This is a valid action because I have checked in an updated iteration, so the old iteration is superseded and moot.
But this is impossible once there is much of any complexity, a multilevel structure involved, links between the WTParts and other documents, other team members working on different pieces of the puzzle, and links to the Resulting Objects of the Change Notice.
wcadmin should have an ability to look at the situation and say, OK, you made a mistake on version A.1, but you'd corrected it and checked it in to A.2. Let's blow out the A.1 and the mistake component that should never have been created.
Best solution I have read so far is the method from Ali Akguner. But I still don't think that would help me in some of these situations. It's a very time consuming precision intensive surgery to undo a simple mistake.
Some years have passed but the issue seems to be the same right? As a mechanical Engineer it happens often, that we re-arrange assemblies. Then we want to delete the obsolete assembly. Is there still no simple way do erase "non latest iterations" in order to keep our Commonspaces clean?
To close this community thread on Windchill "wt.vc.VersionControlException cannot be cast to wt.epm.confilict.EPMNonOverrideableConflictException" error
Summary and list of references: