Cannot purge CAD Documents that are in a promotion request

[gchampoux]

I'm testing purge and found an oddity.
If a CAD Document is in a promotion request, purge will not delete it, even if the promotion was rejected.
Is there a way to override this limitation?

Specifically, when we migrated from Intralink 3.4, we also migrated a huge number of RTP's that were aborted/rejected.
I like the Windchill method better: Delete the promotion request. Couldn't do this in 3.4.

Anyway, I really don't need any of those old, rejected promotion requests.
Can I safely delete them all?

Gerry

[MikeLockwood]

Yes, should be able to delete all the rejected Promotion Requests.

[avillanueva]

We found another quirk in that the entire assembly would sometimes be
added to the promotion request to tagged to it in some fashion. This
included library parts that were used in the assembly. We had issues
purging our library parts b/c of this. I have a script posted (SQL
level) that cleaned this up.


<

[ptc-2607046]

When ProE files that have a family table are checked into PDMLink, each parameter associated with the ProE part/assembly (and is in the family table) is created in PDMLink as a parameter type (e.g. string, number, etc.). In a small number of cases, the user changes the parameter type (e.g. from number to string) during a revision or iteration. PDMLink will not allow the checkin since the parameter type no longer matches the previous revision or iteration.



Solutions to date:

1. Delete all revisions and iterations of the record and reload. This can be an extremely time consuming task since the record may have many relationships per revision/iteration and it cannot be deleted until they are removed. These relationships would need to all be recreated during or after the reload.

2. Update the parameter type at the database level. PTC will not support this change since initial findings show they are not sure where all the changes need to be made and therefore do not know the repercussions.

[jkent]

We fought with PTC on this same issue a while back. They told us to
submit an enhancement request. I believe you can change the type on a
non family table file. Huge design flaw of PDM Link if you ask me.



Love number 2: "PTC will not support this change since initial findings
show they are not sure where all the changes need to be made and
therefore do not know the repercussions." Glad PTC developers know the
ins and outs of the product they designed.

[pwilliams-3]

Steelcase Inc. received a "patch" which disabled the parameter type check in PDMLink. We are now able to checkin objects that have a designated parameter whose data type has changed over it's iteration history. I would push PTC to get the same patch.

Patrick Williams | Engineering Systems | o: 616.698.3766 | c: 616.947.2110
[cid:image002.jpg@01CC711F.4301AD50]

[jimboshieldo]

Who do we contact at PTC to push this? We have the same problem here
which is very time consuming not to mention annoying.



Thanks,

Jim Shields

Design Drafter Specialist

DRS C3 & Aviation Group

A Finmeccanica Company

767 Electronic Drive, Suite A

Horsham, Pa. 19044

215.242.7359

shields@drs-c3.com

[pwilliams-3]

Contact Technical Support.

Patrick Williams | Engineering Systems | o: 616.698.3766 | c: 616.947.2110
[cid:image003.jpg@01CC7127.D262B810]

[pwilliams-3]

Ok, sorry for being vague. If you are having this issue where you receive the following error when checking in objects then contact PTC TS and reference SPR 2071361.

[cid:image001.png@01CC7128.CE74E6A0]

Patrick Williams | Engineering Systems | o: 616.698.3766 | c: 616.947.2110
[cid:image002.jpg@01CC7128.CE74E6A0]