Selective delete in windchill 10

I would question why one would need to bother with this at all.

If it's not the released version, who cares?

(And if it is the released version, why would one want to delete a released file? That's seeking out unnecessary trouble.)

If it's not the latest, engineering won't be working on it anyway.

Those people that should only be viewing the latest can be restricted to only view the latest.

If the older version is somehow a problem, it's superceded by the newer file and can be ignored.

Disk space is not so expensive that a single iteration of a file is going to matter.

This thread is referring to specifically to 10.x but in 9.1 I am experiencing a similar situation. We have a part that was revised and iterated but then it was decided to obsolete the part altogether. Our Document control would prefer to delete the WIP iterations back to the last release. We received errors citing 'Build rules violations' in the failed attempt.

If deleting is not the best practice then what is to be done with the WIP iterations when the part is obsoleted? Or, since its not released, Who cares??? This is more of aBusiness admin questionthan system admin.

Sorry to coopt this thread.

Best,

Bob Lohbauer

In Reply to alfonso medina:

I'm currently admin on a 3.4 install and I like it. Its fine and does what
it was meant to do. (But its dying out in all ways, support, time out
issues, people who know it, users etc.) The CO and other change management
workflows are done on a separate database. Windchill, Team center and
Agile EC all try to merge these two and many other tools as a swiss army
knife for business. The problem being that I never use a swiss army knife
to torque down the heads on my engines. Its always some special tool that
is specifically made for that.

But that's a bad comparison. Software is software and it will do what its
programmed to do, no matter how you package it. The patch is probably a
java plugin with a direct SQL command that bypasses the PDM system and
"dangerously" changes stuff in the database. You can do that by hand, but
its an illusion. And think of the fun you will have later when your
automated migration tool does not take into account some missing data. Fun
times!

To think that deleting A.1 will bring back all the copies of it from emails
in gmail and hard copies and such is an illusion. There are better ways to
use SQL and most of them should be read only for reporting. (in our pdm is
glory case. Oracle guys can hack a database all day long)

So this PDMlink thing, the way it was made to work, will link assemblies,
change notices, emails, comments, pictures etc to a specific
iteration/version of a revision.

rev A.1 and rev A.8 will look completely different. So the stuff attached
to A.1 cannot be reconciliated to use A.8. That is why you must un-link it
first. Its a house of cards.

There are many other ways they could have written PDMlink. Hoever, its out
there now, so if they corrected such a fundamental thing as the way things
are linked to each other, it would take them a long time to make more
profit. imagine having to migrate on each upgrade. Its bad. People loose
data too. its not good for business to correct or re-do the logic of how
you handle the data.

hey go vote, stop reading, there is tomorrow for that.

Typically, I would suggest that non-engineering personnel shouldn’t have access to non released parts. If it’s WIP, only engineering has access.

If there are other departments that need to see parts that are not released yet (like purchasing dept for long lead-time items), there should be a separate life-cycle state the files can be changed into to give those people access.

Now, the problem with leaving the WIP objects in place becomes when a future revision takes place. You can’t really rely on every engineer to remember that one item at WIP should not be used. The solution is more involved.

The first solution to try is to delete the newer iterations back to the released version, which you've already tried.

After that, I would open the released version (part/assembly and drawing), then update my workspace. When prompted to update the work in session, pick NO. Check out the offending files (again, part/assembly and drawing) while in your workspace. Now when you save the files in session (the released files), you'll overwrite the "bad" files with the latest released version. Check in, put a comment into the check in field explaining what you did, and leave it at that.

In this way, in the future when an engineer searches for that file, they will see the WIP version, but it will match the released version, rather than all the changes that are now obsolete.

There may be other ways to get around this, like involving tech support, where you can sort through all these build rules violations. I've simply never taken the time to research it further due to how quick the above method usually ends up being. It's really up to you to decide which is the best for your organization.

In Reply to Bob Lohbauer:

This thread is referring to specifically to 10.x but in 9.1 I am experiencing a similar situation. We have a part that was revised and iterated but then it was decided to obsolete the part altogether. Our Document control would prefer to delete the WIP iterations back to the last release. We received errors citing 'Build rules violations' in the failed attempt.

If deleting is not the best practice then what is to be done with the WIP iterations when the part is obsoleted? Or, since its not released, Who cares??? This is more of aBusiness admin questionthan system admin.

Sorry to coopt this thread.

Best,

Bob Lohbauer

If this is true, you would never use software or most products in the market.

Every software is limited to what it can do as a tool. I can't program it on the fly to allow me to do what I want and how I want.

If I wanted to use my lawnmower to trim the bushes and also as an edger, just because it's not possible does not mean the mower is useless. I should not be able to use the mower for something it was not designed to do. 🙂

You may not like how Windchill restricts you but it may be designed to do so for a purpose. Not saying this is true all the time, but I don't think software should allow me to do everything I want to do and how I want to do it.

🙂

In Reply to Joel Nelson:

Windchill is a real WHAT?
Please tell me you are joking?

PDM, whether it is INTRALINK or something else, is supposed to be a value added tool, and a tool should NEVER prevent me from performing an action that I think and/or know is best.
A tool that I use should NEVER tell me what is right and/or wrong, it should only do what I want and need it to do.

It is me as the user that needs to know what is right/wrong and have the knowledge to being using, otherwise, me as a user has to deal with the consequences.

"Too many people walk around like Clark Kent, because they don't realize they can Fly like Superman"

Maybe it's just me. I'm still having trouble understanding why we care about some random iteration in the middle of a series of iterations that we want to keep.

A.1 --> A.12 (final one Released)

B.1 --> B.12 (final one Released)

C.1 --> C.12 (all at WIP)

If I'm understanding correctly, the origianl request is to delete something like C.3.

Why?

Who cares that it exists?

It's not the released file being used for production.

It's not the latest of Rev C, so engineering won't be using it for new design changes.

The whole request seems rather like a random nitpick.

(There have been explanation for needing to delete all of Rev C (iterations 1 through 12) and the system restricting that deletion. This I understand; a revision is requested then sometime later that request is rescinded.)

In Reply to Joel Nelson:

...especially when it is not company/corporate sponsored and cannot do what I want/need (like INTRALINK 3.4).