Re: FAMILY TABLE RETRIEVAL ISSUE

DELETEME · ‎Nov 11, 2009

We have a library of several fastener family tables. Our problem is that sometimes PDMLink dumps the entire table into a workspace when all we need is maybe one or 2 instances of the table. this is very annoying as it pulls hundreds of unneeded parts into the workspace. And, in addition, many times it shows them as changed. We're on WF3 and WC/PDMLink 8. Any ideas?
This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

Kevin · ‎Nov 13, 2009

Is anyone trying to edit or view the table? If you get dialog that says the family table is not checked out when you have the generic open selecting Continue will cause the entire tabe to be downloaded to the workspace.

DELETEME · ‎Nov 13, 2009

"Kevin Demarco" wrote:

Is anyone trying to edit or view the table? If you get dialog that says the family table is not checked out when you have the generic open selecting Continue will cause the entire tabe to be downloaded to the workspace.

Kevin · ‎Nov 13, 2009

I'm not sure why it's causing a change. I know our CAD administrators had problems when switching from intralink to Windchill and PDMLink. I think they ended up redoing the tables. I also seem to remember nested family tables causing more problems. Although you can exclude instances from being downloaded to a workspace most people here find the instance they want to use and make a copy of the instance in their workspace to get away from the family table issues.

DELETEME · ‎Nov 14, 2009

"Kevin Demarco" wrote:

I'm not sure why it's causing a change. I know our CAD administrators had problems when switching from intralink to Windchill and PDMLink. I think they ended up redoing the tables. I also seem to remember nested family tables causing more problems. Although you can exclude instances from being downloaded to a workspace most people here find the instance they want to use and make a copy of the instance in their workspace to get away from the family table issues.

AntonioVillanue · ‎Jun 27, 2010

PlanetPTC needs to stop retrieving old posts but I've extensive experience with this issue. The problem lies with the user or the family table itself. Its being modified. It could be implicit. Were the mass properties run and saved with the entire FT? Is there a layer change issue? It could also be a relation issue. If you have a parameter or relation attribute that is not a column in the FT, it could change when you retrieve an instance. Since this causes a modification to the attribute, the entire FT gets modified and all instances end up in the workspace.

ptc-93941 · ‎Jul 27, 2010

What I have found in a recent migration from Pro/INTRALINK 3.4 to PDMLink 9.1 are un-verified family tables causing this problem. It appears that quite a few families had instances added and not verified, or the entire table was added and not verified. Now, in PDMLink - if I revise and check out (because they are in a release type of state), verifiy, check back in and put the state back this problem goes away.

Now what I would like to find out is - has anyone made an auto-verifier for all instances in the database? Anyone?

huggre · ‎Aug 04, 2010

Frank

This problem is very familiar to me, we had the same problem some time back when moving from intralink to PDMLink.

My guess is that you have relations in your generic model that in some way changes the model as it regenerates.

As soon as PDMLink detects any changes to your model it will display the "check out" question dialogue.

Even if you chose "Continue" and not "Check Out", it will retrieve all the instances to your workspace.

The only stabile solution i have found to this problem is to remove all relations from the generic and add all instance variations to the fam. table.

Hope this helps

Hugo

CM10 · ‎Aug 05, 2010

The parts aren't being changed to my knowledge, but there is a setting in config.pro that causes mass properties to be calculated automatically, to prevent this set the following "mass_property_calculate" to "by_request". Also, some people don't realize that at the assembly level, with the layer Settings set to "All Submodel Layers" any layer change changes the models below, causing the part to be changed. You can set this to "No Submodel Layers". Now, I've done these things and it still pulls the instances, even though it doesn't show them as modified. This is getting old.

BrianMartin · ‎Oct 05, 2011

If anyone is still struggling with this, I do have some feedback I can add. This is a very old thread though so I don't know if its worth getting into if the problem has been resolved.

Patriot_1776 · ‎Nov 03, 2011

Nope, to my knowledge it's still an issue. I have family tables of fasteners with hundreds of parts for each screw head type. So, it adds up VERY quickly.

BrianMartin · ‎Nov 17, 2011

Hi Frank...

I've opened a support call with PTC over this problem. We have fasteners which have been verified, have no layer issues, and were working well with Wildfire 3 and Windchill 9.1 Now suddenly they're showing up as modified when users are doing nothing more than retrieving the items.

There are NO relations and this problem only started when we switched to Wildfire 5.0 Nothing else was updated. This definitely points to a problem in WF5. There were previous problems reported in WF4 under TAN 143955. It seems like these problems have resurfaced.

If we get a resolution from PTC, I'll report it here for everyone.

Thanks!

-Brian