Question
Family Table fixing
Using PDMLink 9.1. I had a user change the names of some the instances
in a family table and check them in. The result as you can imagine is
that the old instances are stuck with the previous iteration of the
generic and the assemblies in his workspace are complaining. Looking
for the steps to reverse this. I will try to replicate on my test server
but if anyone has documented this, please send. I know it involves some
sleight of hand with PDMLink which I've done before at great pains. Here
is what I do know:
* Two different generic instances cannot coexist in same
workspace.
* Cannot check out previous instances due to above.
* Cannot delete latest iteration of generic since it means
deleting new instances, cannot due in same delete action.
Ugh, what a mess.
Antonio Villanueva - Sr. Software Engineer - ISR Systems
UTC AEROSPACE SYSTEMS
100 Wooster Heights Road, Danbury, CT 06804
Tel: +1 203 797 5682
antonio.villanueva@utas.utc.com www.utcaerospacesystems.com
CONFIDENTIALITY WARNING: This message may contain proprietary and/or
privileged information of UTC Aerospace Systems and its affiliated
companies. If you are not the intended recipient please 1) do not
disclose, copy, distribute or use this message or its contents, 2)
advise the sender by return e-mail, and 3) delete all copies (including
all attachments) from your computer. Your cooperation is greatly
appreciated.
in a family table and check them in. The result as you can imagine is
that the old instances are stuck with the previous iteration of the
generic and the assemblies in his workspace are complaining. Looking
for the steps to reverse this. I will try to replicate on my test server
but if anyone has documented this, please send. I know it involves some
sleight of hand with PDMLink which I've done before at great pains. Here
is what I do know:
* Two different generic instances cannot coexist in same
workspace.
* Cannot check out previous instances due to above.
* Cannot delete latest iteration of generic since it means
deleting new instances, cannot due in same delete action.
Ugh, what a mess.
Antonio Villanueva - Sr. Software Engineer - ISR Systems
UTC AEROSPACE SYSTEMS
100 Wooster Heights Road, Danbury, CT 06804
Tel: +1 203 797 5682
antonio.villanueva@utas.utc.com www.utcaerospacesystems.com
CONFIDENTIALITY WARNING: This message may contain proprietary and/or
privileged information of UTC Aerospace Systems and its affiliated
companies. If you are not the intended recipient please 1) do not
disclose, copy, distribute or use this message or its contents, 2)
advise the sender by return e-mail, and 3) delete all copies (including
all attachments) from your computer. Your cooperation is greatly
appreciated.