Community Tip - If community subscription notifications are filling up your inbox you can set up a daily digest and get all your notifications in a single email. X
Welcome to the wonderful world of Windchill.
As you have discoverred, you can only delete the latest version, or all iterations of the latest revision.
Gerry Champoux
Williams International
Walled Lake, MI
In Reply to Ron Rich:
Ok so this was possible in ILINK3.4 how do you do it in WC10. See picture below. I would like to delete 8010-120_mfg.asm version A.1 from the data base. Unfortunately I cannot I can delete A.4 through A.1. Purge is not the answer. I do not want to delete from A.1 through A.3 and leave only A.4 I would like to selectively delete these items from the database.
Has anyone ever received this toolkit deletion patch for Windchill 9.1, and willing to share it?
I've requested it from PTC, but they are stonewalling me.
Gerry Champoux
Williams International
Walled Lake, MI
In Reply to Joe Kent:
Only way I know of doing this is using the wctk DeleteObjects. You can specify a specific Revision and Iteration in a csv file and run the tool.
Here is the patch.
10.0-M0X0_WCTK_2.0 Windchill Toolkit [Seq 05]
[cid:image002.png@01CDBC1E.C95DC960]
Joe Kent
Engineering Systems Administrator
R&D/Leverage(tm)
Structural Brand Development / Mold Manufacturing
"With Us, Ideas Take Shape"
Tel: 816-525-0353 x6527
www.rdleverage.com<
Innovations in packaging design!
Innovations in mold manufacturing!
Learn more here www.rdleverage.com<
Can't argue with that.
But what about deleting unreleased objects?
Windchill still does not allow such.
Simple example:
User inadvertantly rolls the revision of a model to the next letter.
Weeks go by before anyone notices.
By this time, many iterations have been checked-in, but nothing released.
Once notified, I (the admin) try to delete them. Normally, I should be able to do so. (all iterations of latest rev)
However, the model is now in use any many assemblies.
Windchill won't allow me to delete the revision of the model (a part) because it is in use.
Some would say that if I were allowed to delete the model, those assemblies will fail to regenerate.
Yes! That's exactly what I want to have happen, so that the designers will know they need to fix their assemblies with the same model at correct revision.
In short: Deleting stuff like this should be allowed for the admin.
Gerry Champoux
Williams International
Walled Lake, MI
In Reply to alfonso medina:
Intralink 3.4 is a pretend PDM. we pretend we release something then we go
back and delete it and replace it with something better.
windchill is a real PDM. You release something and that's it, there is no
going back to cleanup the trail... especially if you waited several months
to discover something. so what do you do if you need to delete rev A and
rev B is already released? just roll back every single linked item to all
A.X revisions and then delete one at a time as required, then redo all the
work. Or go to C with rev A.4 as the start point then go to rev D with rev
B as the start point. Hey if A is already in someone's hand as paper,
forget about deleting it from your db.
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).
I single iteration in the middle of a sequence has to be deleted for legal reasons? I'm not touching that with a 10-foot pole.
When you try to delete that iteration and windchill forbids it, well, there's your warning not to delete it.
In Reply to Michael Reece:
Whether you understand why or who cares is irrelevant. Whether you want to remove it for legal reasons of for other maintenance reasons, I should be able to remove that object.
If removing the object is doing something unreasonable to the dataset, Windchill should warn me, but if I have sufficient permissions, it should not stop me from removing C.3