I think we agreed on the fact that the solution would be to extract the assemblies from the PLM for processing them with Task Scheduler and Refreshing the Standard Parts.
Since this is not possible, due to the restriction of your PLM, the workaround is to allow the approved assemblies to be opened resolving the links with one of the methods discussed in this thread, while the new assemblies can use the standard parts located on the new server without problem.
I don’t see other solution, but if you think differently, please, let me know.
Thanks and regards,
I accepted the solution we concluded...... but I have had one final thought on this. I was thinking as we are to kill the P: drive to move to L: and we have the same file structure on L: as we had on P: then would it be possible to map the same location as L: and P:
I would keep the project file configured to use L: as the CC but add P: as a workgroup.
I have just tried this on my laptop and opened an assembly perfectly. The CC parts reference to P: but these are of course the files on L:
Can you see any issues with working like this before I implement it?
If I’ve understood it correctly, basically, this is the same configuration of the workaround we agreed on.
In this case, you should not even see the paths in red because they are not nested.
The issue is the one we have already discussed.
That is, for the “approved” assemblies the CC parts resolved with the Workgroup path are not considered 100% as standard parts, so, if you do a Refresh, they won’t be seen as such.
Instead, no problems for the new assemblies that will take the Standard Parts form the CC File folder when you insert them.
I hope I’ve answered to your question.
Yes you confirmed what I thought. It is just nice for me to make sure so thanks again for the quick reply. This is the procedure we will employ.