Thanks for the feedback. This is what I kind of expected to hear.
The background of the family table is this. About 15 years ago, we used family tables for a lot of our common parts like timing sprockets. We modeled one generic and build into it the features and intelligence to morph into XL, L, H, HTD, Polychain, w/wo hubs, flanges, etc. That FT now has about 100 instances in it. We were also a little lazy in that if the part was older (>15years) and had been represented by an ACAD drawing, we left the drawing alone and just used the Pro/E model as more of a place holder in our assemblies.
About 2 years ago, we started down the Windchill / PDM road. We also started a push to make our Pro/E data more accurate and if a part is in Pro/E, the drawing should be as well. Unfortunately due to staffing, this is done when the engineers have free time to do it. What we are finding is that as we try to create a drawing of a sprocket, there is always some parameter we didn't orignally put in the table that should be in order to track the information correctly with the part. Adding something to the generic table requires checking all the instances out. Some instances are in the RELEASED state (pretty much read only) and some are in a HOLD state, etc....... Pretty much a huge PIA to make all things editable, make the additions, and get the instances back to where they came from. (Other processes depend on accurate states of parts).
The feeling here is that with PDM, family tables are not well suited for large collections of similar parts (except maybe hardware) and everyone wants to get some parts out of tables and make them standalone. I was hoping someone had found a way of doing that, but my experiments were leading me to the conclusion that it was damn tricky and not worth the work.
thanks again
Michael Kuehnen, Kansas City