We store generic parts and their instances of the family table in the same folder, and need the ability to set a preference that automatically stores instances, when added to the family table, in the same folder as their generics.
Here is the main reason why the instances should always reside in the same folder as the generic. Let's say you have a context in Windchill that is open or readable to over 1000 user's in your company from 3 different continents. Now you have this other context called "supersecret" which only 10 user's have view access. One of these 10 user's creates a family table and places the generic and instance into this supersecret folder...this is all great, nobody in the company can see the objects as intended. Now 2 years later, an engineer adds a new instance to this family table and places in a readable context and adds to a collaboration assembly that many users will open. Here are some examples of what I've experienced over the years when a user tries to open an assembly containing this instance
Wasted Admin time: User gets cannot be retrieved errors so an admin has to investigate. (Lost time for user also)
Creo's ability to call for objects on the fly when the objects don't reside in the workspace get's impacted in this scenario. And it's not only for the generic in the secret folder it also impacts creo's ability to call for other objects the user has view access to.
My testing from Creo Parametric 4 shows that this issue is even more sensitive. Once the user tried to open an instance where the generic was in a hidden folder, the user's workspace became corrupted. They were no longer able to add to workspace or let creo call for objects on the fly that don't exist in the workspace. This took us a week to figure out...
A company has more than 1000 users with view access to a library context in Windchill and then there are only 10 users that have view and write access to a context called “supersecret”. One of these 10 user’s creates a family table with instances and checks into the supersectret context. This is great…all the other user’s can’t see any of the objects as intended. Now 2 years later, the engineer adds a new instance and checks the instance and his collaboration assembly into the library context. In this collaboration environment, other engineers outside the supersecret group open the collaboration assembly. This is what can happen when connected to Windchill:
Wasted Admin time: The user gets cannot be retrieved message and the admin has to spend time to resolve.
Creo Parametric’ s ability to call for objects when working with simplified reps gets impacted. Yes, we’ve seen it where objects that the user has access to cannot be retrieved into the workspace when this instance comes into session. Yes, objects other than the instance won’t get added to the workspace.
Now it seems Creo Parametric 4 is even more sensitive to the scenario. The user opened up an assembly and received the cannot be retrieved for the instance(which is good), but basically ended up with the inability to add or open any objects after this occurred. The workspace became corrupted…we had to delete workspace and start over. This took us a week to figure out…
I store my generic files in a folder above the instances, which are broken down by type of part they are. When I add a new instance, I make sure I add it to the proper folder.
One lesson I learned about family tables is: Use a librarian to create and maintain standard hardware family tables! Do NOT let every user create or modify them. Keep the list of Librarians down to a select few whom you can trust to create good robust models and family tables. If the file needs to be in the supersecret for development work, then fine, but when the added part is need by all users, move the generic and instances to a common folder. I guess it depends on what is in your family table, but why not just create them all for everyone to use.
You are right, a librarian is a great idea, but unfortunately not applicable to our environment. My example may have been bad...the issue normally occurs when family tables get added to a development folder and then the user leaves to another group or another person modifies the file. I used Library, because that is synonymous with view access to all users.
