Skip to main content
B
BillRullan1-Visitor
1-Visitor
August 25, 2011
Solved

deleting files in WindChill - impossible?

  • August 25, 2011
  • 8 replies
  • 25312 views

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?

    Best answer by cgorni

    To close this community thread on Windchill "wt.vc.VersionControlException cannot be cast to wt.epm.confilict.EPMNonOverrideableConflictException" error

     

    Summary and list of references:

    • The above error has been given in some older Windchill releases when some Family Table (FT) version’s members were missing in the Delete operation.
      • The message was incomplete, and misleading, and fixed in Windchill 9.1 M070 and 10.0, see CS25735
      • In fact all instances being part of a Family Table version should be included when trying to delete a Generic (if not included in other FT versions)
      • A more detailed conflict should now be issued:
        • Unable to delete CAD Part - delete_ft_inst.prt, A.1 without also deleting CAD Part - delete_ft_inst1.prt, A.1.
    • Deleting CAD Documents may be a complex operation and requires a good understanding of the relationships between the different objects.
      • Important steps are listed in the article CS44609
    •  The complexity may increase when Family Table instances are involved, specially with legacy or migrated data.
      • WinDU and WinRU utilities can be used to perform Data analysis and healing
      • Refer to article CS211171 for more details and instructions

    8 replies

    D
    DmitryTsarev17-Peridot
    17-Peridot
    August 26, 2011

    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?

    B
    BillRullan1-VisitorAuthor
    1-Visitor
    August 30, 2011

    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.

    J
    jkent1-Visitor
    1-Visitor
    August 30, 2011

    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.

    cadnamepro_versiondoc_is_latestft_statusft_idft_version
    locating_ring.prt-..40gen(t)6503118-..1
    zlocrindme6500.prt-..40inst6503118-..1
    zlocrindme6501.prt-..40inst6503118-..1
    zlocrindme6501ln.prt-..40inst6503118-..1
    zlocrindme6502.prt-..40inst6503118-..1
    zlocrindme6503.prt-..40inst6503118-..1
    zlocrindme6504.prt-..40inst6503118-..1
    zlocrindme6505ln.prt-..40inst6503118-..1
    zlocrindme6510.prt-..40inst6503118-..1
    zlocrindme6511.prt-..40inst6503118-..1
    zlocrindme6520.prt-..40inst6503118-..1
    zlocrindme6521.prt-..40inst6503118-..1
    zlocrindme6522.prt-..40inst6503118-..1
    zlocrindme6524.prt-..40inst6503118-..1
    zlocrindme6534.prt-..40inst6503118-..1
    zlocrindme6535.prt-..40inst6503118-..1
    zlocrindme6536.prt-..40inst6503118-..1
    zlocrindme6537.prt-..40inst6503118-..1
    zlocrindme6541.prt-..40inst6503118-..1
    zlocrindme6544.prt-..40inst6503118-..1
    zlocrindme6548.prt-..10inst6503118-..1
    locating_ring.prt-..50gen(t)6503124A..1
    zlocrindme6500.prt-..50inst6503124A..1
    zlocrindme6501.prt-..50inst6503124A..1
    zlocrindme6501ln.prt-..50inst6503124A..1
    zlocrindme6502.prt-..50inst6503124A..1
    zlocrindme6503.prt-..50inst6503124A..1
    zlocrindme6504.prt-..50inst6503124A..1
    zlocrindme6505ln.prt-..50inst6503124A..1
    zlocrindme6510.prt-..50inst6503124A..1
    zlocrindme6511.prt-..50inst6503124A..1
    zlocrindme6520.prt-..50inst6503124A..1
    zlocrindme6521.prt-..50inst6503124A..1
    zlocrindme6522.prt-..50inst6503124A..1
    zlocrindme6524.prt-..50inst6503124A..1
    zlocrindme6534.prt-..50inst6503124A..1
    zlocrindme6535.prt-..50inst6503124A..1
    zlocrindme6536.prt-..50inst6503124A..1
    zlocrindme6537.prt-..50inst6503124A..1
    zlocrindme6541.prt-..50inst6503124A..1
    zlocrindme6544.prt-..50inst6503124A..1
    zlocrindme6548.prt-..20inst6503124A..1

    J
    jkent1-Visitor
    1-Visitor
    August 26, 2011

    We had a huge issue purging family table objects. Ended up getting a delete utility from PTC.

      P
      PrebenReventlow_1036971-Visitor
      1-Visitor
      August 30, 2011

      We have an issue with deleting/purging in Windchill as well.

      Kent, could you possibly share the delete utility?

      J
      jkent1-Visitor
      1-Visitor
      August 30, 2011

      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.

        S
        ShawnPete1-Visitor
        1-Visitor
        May 29, 2012

        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!

        B
        BillRullan1-VisitorAuthor
        1-Visitor
        May 30, 2012

        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.

        B
        bsindelar1-Visitor
        1-Visitor
        October 9, 2015

        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.

        S
        slawson1-Visitor
        1-Visitor
        March 14, 2013

        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

        R
        rvanveerdeghem12-Amethyst
        12-Amethyst
        July 18, 2014

        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?

        T
        tcurry10-Marble
        10-Marble
        April 8, 2015

        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).

          A
          ALIAKGUNER7-Bedrock
          7-Bedrock
          October 8, 2015

          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

          S
          shartzell1-Visitor
          1-Visitor
          October 19, 2015

          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.

          D
          doehr1-Visitor
          1-Visitor
          February 22, 2016

          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.

            T
            tcurry10-Marble
            10-Marble
            March 18, 2016

            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.

              T
              Thomasino3-Newcomer
              3-Newcomer
              January 14, 2020

              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?

              C
              cgorni16-PearlAnswer
              16-Pearl
              June 20, 2022

              To close this community thread on Windchill "wt.vc.VersionControlException cannot be cast to wt.epm.confilict.EPMNonOverrideableConflictException" error

               

              Summary and list of references:

              • The above error has been given in some older Windchill releases when some Family Table (FT) version’s members were missing in the Delete operation.
                • The message was incomplete, and misleading, and fixed in Windchill 9.1 M070 and 10.0, see CS25735
                • In fact all instances being part of a Family Table version should be included when trying to delete a Generic (if not included in other FT versions)
                • A more detailed conflict should now be issued:
                  • Unable to delete CAD Part - delete_ft_inst.prt, A.1 without also deleting CAD Part - delete_ft_inst1.prt, A.1.
              • Deleting CAD Documents may be a complex operation and requires a good understanding of the relationships between the different objects.
                • Important steps are listed in the article CS44609
              •  The complexity may increase when Family Table instances are involved, specially with legacy or migrated data.
                • WinDU and WinRU utilities can be used to perform Data analysis and healing
                • Refer to article CS211171 for more details and instructions
                Terms & ConditionsAccessibility statement