AnsweredAssumed Answered

The Mysteries of External References

Question asked by Bill Florac on Mar 7, 2015
Latest reply on Apr 30, 2017 by Amen Allah Jlili

We are constantly having problems where users are copying files from a shared repository to a local folder for their own use and when they open up the assembly, it gets/edits the parts from the shared repository rather than the same folder. I have tried every API call I could find in both the SW library as well as the Document Management library (where I would prefer to do it) to attempt to warn users but I have come to the conclusion that there is no way to predict where SW will actually get components from for an assembly.

 

I have read all the help files that describe the search paths used and they are just not correct.  I can take assembly XYZ with parts 1,2,3 copy the entire contents to a new folder, open up XYZ and have part 1 and 2 point to the other folder while part 3 points to the new folder. Even though part 3 there, right in the same folder.

 

The only way I have found knowing for sure is to open up the file in SW, resolving all components and iterating down the components list to see what SW actually did.

 

I have found no way of forcing SW to generically look in the same folder as the assembly first as a file is opened or resolved. I just want an option to look locally first.

 

I have only two ways to force SW to look locally first. Neither is particularly fast on large assemblies:

  • The first is to use SetSearchFolders() to add the local path to SW, open the file, resolve all components and save the file.  Of course you have to do this on ALL assemblies in a nested assembly.
  • The second is to do a Pack and Go to a zip file (doing it to a folder does not work). And then, you can take the assembly files from the zip file and replace them with the originals.

 

Anyone else have this problem and worked around it?

 

Anyone else know a way to detect it?

 

Bill

Outcomes