Pruning the Hedges - Deleting models from PDMLink

[avillanueva]

Repost of my blog:

remove this reference on the way back in (actual steps are a bit more
involved). So now, that reference is gone from the drawing. Great.
Another purge to remove old iterations.

Here is where I lose it. I've spent a considerable amount of time
removing ONE model. The iterations of those drawings refuse t...

[MikeIbosh]

Antonio,

Well, that's going to start a Friday Rant!!

I can't agree with you more!! Once you combine the relations between
Models, Drawings, WTParts, New View Versions, ESI Transactions Etc., it
really gets to be impossible to delete things from the system. Happy
Friday All J

Mike

[achukwuka]

That probably because the Windchill database is a normalized database where almost all database objects have references and relationships to each other. Which makes things difficult to delete at times.


Thanks

Alexius C. Chukwuka
Infrastructure Analyst
JDPS Division SAP BASIS Team
John Deere Power Systems

[ocorten-2]

Count me in as well. I've complained about this several times before.

It's basic functionality which was always there in Intralink 3.4.
For me it's one of the major flaws of WC.

PTC, if you are listening. Just give us admins more control over the objects. I know you are concerned about data integrity, but that is just the thing we admins are pursuing. Let us decide if we want to break all those dependencies or not.
Give us 10 warnings about breaking all dependencies to other objects, but in the end just do it if we want you to continue. Just delete the object and break all it's dependencies.

We don't want purge workarounds, external delete tools, etc. Just a powerfull delete tool inside WC.



Kind regards,

Olaf Corten





Olaf Corten
CAD/PLM Manager
Fico B.V.
Ratio 6, Duiven
Phone: +31 26 3196215
Mobile: +31 644548554
www.besi.com






From: "Ibosh, Michael" <->
To: "Villanueva, Antonio" <->, -
Date: 18-03-2011 14:49
Subject: [solutions] - RE: Pruning the Hedges - Deleting models from PDMLink



Antonio,
Well, that’s going to start a Friday Rant!!
I can’t agree with you more!! Once you combine the relations between Models, Drawings, WTParts, New View Versions, ESI Transactions Etc., it really gets to be impossible to delete things from the system. Happy Friday All J
Mike

[LewisLawrence]

Antonio,

As a long term Windchill administrator, I find that the most frustrating thing about this issue (which is not just limited to CAD data), is that there are no easily accessed and immediately obvious out of the box actions, reports or other tools to help with analysis of the data.

Depending on the objects involved, just determining when one object is related to an old iteration of another object requires a lot of effort, in some cases you have to build a report template to return the numbers. That or you just try deleting it repeatedly and use the error message returned (that is some clicks away) in the Event Manager every time to then go and take action on the offending item as a completely separate activity.

Clearly there are gaps in the toolset, and in an ideal world as soon as you tried to delete something there would be a nice informative screen that shows you the dependants and lets you investigate them and take action on them from the same screen. All before you ever tried to delete anything, as there will be times when you see the relationships when you decide not to delete it after all. I don’t think it should be possible for anyone to compromise the data model, but we clearly need better tools to help with pruning.

For all the naysayers out there who are likely to respond with “Disk is cheap and you shouldn’t be deleting anything anyway”. For now I will quietly grin at your naivety and will later laugh and point when you are posting on here with performance issues.
-----

Lewis

[avillanueva]

Amen to last line. I recently ran my purge report
<

[kpritchard]

Yep - agreed!!

After exhausting other alternatives I've created a "Trash Heap" Context whereoffending datalanguishes for eternity, hoping for a brave new tomorrow and a Purge manager capable of putting it out of it's misery.

I'd love to see a Purge method Robot that could be called from a Workflow, and it would be really nice if the purgequery manager did not addin the all but latest iteration criteria.

Dare to dream PTC User, dare to dream.

[MikeLockwood]

We also have a context (name=Hidden) for this purpose, available to only a central service group. It's getting populated quickly.


We bought Windchill Archive about 4 years ago (almost $25000) and played with it for a long time. Got it to work on a test system with 100 objects, but it always crashed or just stopped responding on a rehosted production system. At the time tech support seemed to have no one who could even spell Archive and wasn't much help. We gave up on it and stopped paying maint - maybe someday will revisit.

We would still like to purge at least printable drawings, even if it's necessary to leave all models behind - but there is no way to isolate CAD Docs (EPM Doc's) into Drawings and everything else - having Number as a criteria would allow this.

[gchampoux]

We are still on Intralink 3.4 and I am still preparing Intralink 9.1 for deployment later this year.
This issue is important me as well, especially for standard fasteners.
We always delete prior versions/iterations when new versions are checked-in, to ensure that the old ones are never used again.
This is commonly a concern when pulling up an assembly with the As-Stored dependancy configuration.

Some of the replies to this issue have implied that instead of deleting interations, they can be moved to another folder or context that is unaccessable to the users.

In 3.4, you could not move an individual iteration (version). If you moved an object, all revisions/iterations moved together.
Is this different in Windchill?

As an alternative, I was also thinking of changing the state of unwanted iterations to "Obsolete" and deny access to all Obsolete objects. Should that work?

Gerry

[MikeLockwood]

On one point below...
Have to be very careful denying access to Obsolete.

If per the case below, this would be ok:
A Obsolete - users have no access
B Obsolete - users have no access
C Released - users can read
On Search, system will supply C Released and not let the user have access to A or B (as desired)
This of course requires setting state on the non-latest Revision

But, given:
A Released - users can Read
B Released - users can Read
C Obsolete - users have no access
On Search, system will supply B Released and not let the user know that C is Obsolete.

But, it gets much more complex considering draft iterations.

[gchampoux]

I don't think I have an issue here.

My only requirement is to delete (or hide) objects that are unwanted and are not the latest.

Same applies to your 3rd example.