Can't delete the latest version of a family table when one instance has only one version.

[jfrankovich]

As many of you may already know, in Windchill it is not possible to delete the latest version of a family table if any one of the instances in that family table has only one version - the reason being that you are deleting ALL versions of that instance. (see example below)

This is an "old" issue with family tables, but I issued a call on it recently just to see if there were any improved workarounds. Suffice it to say, there are not. (CS21661 is not a very good workaround at all.) And I was not pleased to hear from TS that even though they see this issue from customers and have raised it will R&D, it is generally dismissed for some unknown reason.

Do others have issues with this? This would seem to be a simple exception to allow in cases where the A.0 object is not related to any object other than the most recent family table version.

Just wondering,
John Frankovich

Consider the following example:
You have a family table object X [A.4] with instance X1 [A.3]. A user incorrectly adds instance Y1 to the family and checks it in, yielding X [A.5], X1 [A.4], and Y1 [A.0].
Deleting the latest version of X [A.5] would delete the latest version of X1 [A.4], but would require WC to delete ALL versions of Y1, which it will not do unless you select 'delete all versions'. But selecting that will obviously delete all versions of X and X1 as well!

[proed]

Hi, we also run across this issue when trying to clear up old family table files. We have exploded many family tables in the past, I'm glad I did most of them before we migrated to Windchill!

I've also had a PTC tech support case last year, attempting to remove instances, though I'm usually trying to purge non-latest instead of latest as mentioned by John.

Anyway, our temporary 'solution' is to move unwanted to files to a context that has no public access so they're essentially hidden from everyday users.

Edwin

[DonSenchuk]

Yes, it is an issue. While that CS isn't very elegant, it does work. In fact, I generally don't even bother with the purge then delete portion. Just making it stand-alone and then renaming it to "junk12345" or something is enough.

My guess is it's dismissed by R&D because of a combination of 'too much effort/too hard vs. the frequency this occurs' and 'developers not using software the way end users do.'

[jfrankovich]

I can't bring myself to use the CS solution because deleting all prior versions of a perfectly fine historical family table object seems like an extreme way to correct a simple user error. I think renaming and moving the "junk" object to a private context is a bit better.

It is just very disappointing that we can't undo a simple mistake like this. I would think that developers would understand that the workaround is heavy handed. I can't think of a situation in code development that would require purging all previous versions of good code in order to fix a sudden errant commit of bad code.