Let me tell you our problems with family tables + PDMLink.
Some people say you can checkout only one instance and the generic, and send
it back to PDMLink. We don?t do that because the instance is then linked to
an old iteration of the generic and that can give problems.
So when we modify 1 instance we verify and modify every instance. First
problem is that means lots of instances get out of date for a lot of people.
To illustrate the second problem I have to explain how we deal with states
Released and Design in my company:
Final, usable objects are in state Released.
Objects being changed are in state Design.
If you want to modify a Released object you create a new revision in state
Design, then check out to the Workspace (you only can checkout objects in
state Design here, unless you are an administrator)
When you have finished the modification you check in, create a Promotion
Request with the objects you want to take to Released and these objects
change to state ?Under Review? until an Approver accepts the change. Then
they go to state ?Released? and we are in step 1.
When we have to add/modify an instance of a family table sometimes we have
to create a new revision only for one instance. Then the user has to ask the
administrator (that?s me) to set the state of the rest of the family table
manually to Design, so they can check out things.
When they make changes and get their objects promoted to Released the
administrator always has to set the state of the instances that are still in
Design to Released because they were not added to the Promotion Request.
As a side note, sometimes the users create by mistake a new revision of
instances they shouldn?t have. Undoing this mistake is difficult, especially
if the user has used the new revisions in other assemblies, because PDMLink
won?t allow you to delete things.
Third problem: if you want to delete an instance from a family table because
you decide it shouldn?t be used anymore. If you delete it the previous
iteration of the instance is still in the database, linked to the previous
iteration of the generic. If it is ever needed in a Workspace it will bring
the corresponding iteration of the generic (which may be outdated for the
rest of the instances). If, to make things worse, you also need an instance
that was later added to the generic in that Workspace, PDMlink won?t be able
to bring both iterations of the generic to the Workspace.
It?s not so difficult to do this. Imagine you have created an instance in
the family table and you gave it a temporary name. You checkin, then decide
the definitive name. If you open the family table and overwrite the name of
the instance you are deleting and creating a new instance at the same time
(I have seen this happen). The good way of doing this is renaming in the
server, and then synchronizing.
All these examples are not from my imagination. They have happened in our
company and they will happen again for sure.
To summarize, this week a user asked me how to do one retaining ring he
needed. When I told him, ?Just do a normal part, don?t add it to any family
table? his face lit up and said ?Good, then I have no more questions?.
Regards
Daniel Garcia
