17 Replies Latest reply on Apr 30, 2017 7:24 PM by Amen Allah Jlili

    The Mysteries of External References

    Bill Florac

      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?



        • Re: The Mysteries of External References
          Jason Moss

          All I can offer is another work around, rename the network folder before you open it in SolidWorks. Then it should load on local files. I noticed this crazy behavior also when I copied over network projects to my local drive and then after some time or a network restart, where I thought I would be OK, I found out SW actually had parts loaded off the network still, rather than using my local copy. Frustrating since you may be archiving off the network copy thinking your local copy is the newest and then the next day, you spend your morning figuring out what happened to your assembly!

          • Re: The Mysteries of External References
            Pablo Jorge

            Could has sense to work with the option " Do not create references external to the model" selected?


            I have not tried, but I suppose SW automatically use the function " full define sketch".

            • Re: The Mysteries of External References
              Mike Philipps

              After you have saved the assembly to another file.


              You need to select the assembly file to open as shown below, in the bottom right hand corner you will notice the "references" tab.


              If you select that tab, you will get a list of all the parts and the location that SW is picking them from, you can then change the file location so the next time it will take the file(part) from where you want.



                • Re: The Mysteries of External References
                  Mike Philipps

                  Hi Bill,


                  This is the reference box I was talking about on Friday. You can see how it references the parts and file locations for the assembly. By clicking on the part file, it allows you to search for another part or location.


                  I use this box whenever I have a question of where SW is referencing the part, assembly, drawing file from what location. I know it works better on small assemblies.

                  Capture 2.JPG

                  I hope this helps

                    • Re: The Mysteries of External References
                      Bill Florac



                      Yes, I'm aware of that. It does allow you to edit locations but it suffers from the same flaw in that it shows you a "guess" before the file and it sub-assemblies are resolved. The only what to be sure is to actually open the assembly and resolve sub-assembly and component it contains and then use the File | Find References feature.



                  • Re: The Mysteries of External References
                    Bill Florac

                    Mike, the issue is not caused by renaming (and your suggestion above does fix that). It has to do with the search paths that SW uses.  SW does not provide anyway to manage this nor a way figure out how it found files but I am sure a that the details in the SW documentation are not complete.

                    • Bob creates assembly A with parts 1, 2, 3 and puts it in a shared folder on the network
                    • Deb copies the files from the same shared folder to her local drive
                    • Deb opens assembly a and find parts 1 and 2 local and part 3 is referenced to the copy on the shared folder. It does not matter if part 3 is sitting there right next to parts 1 and 2.
                    • To make it worse, Deb does not realized this and modifies part 3. She then zips up her local files and sends them to Joe via email. Now Joe has the wrong version because the update file was not local.
                    • If Deb had looked at "File References" she still might have missed it unless she had set the entire assembly to Resolved.


                    Easy to manage if there are a few parts but if you have and assembly and sub assemblies of hundreds of parts it is very hard to manage.

                      • Re: The Mysteries of External References
                        David Sheridan

                        Hi Bill,


                        I'm glad that you posted this issue.  This is a huge problem with SolidWorks.  It is very unnerving when files locations are not reliable or clear in a CAD system.  I spend a lot of time checking file references in order to prevent wrecked assemblies and lost parts.  Often I have found that SolidWorks Explorer has a reference that is different from the reference when I do a Open (References...) for and assembly or after a assembly is loaded File-Find References.  I usually do not trust SolidWorks Explorer for assembly references.


                        The article by Darin Grosser at DASI Solutions from 6/19/2014 may help you:


                        "Search Path Order for Opening Files in SolidWorks"

                        Search Path Order for Opening Files in SolidWorks | DASI Solutions Blog




                        In the article I have found item:

                        2)  REFERENCE DOCUMENTS PATH: 

                        to be very helpful for correcting file locations but it is an extra step that takes time.


                        The API is:

                        2012 SOLIDWORKS API Help - System Options > File Locations

                        Show folders for - Referenced Documents - Folders


                        ISldWorks::SetUserPreferenceStringValue(swUserPreferenceStringValue_e.swFileLocationsDocuments, <Value>)

                        String value


                        I think item:

                        4) LAST PATH USED BY THE SYSTEM:

                        can be problematic and the only way to avoid it seems to be a manual shutdown of SolidWorks, arrgh!  If you find a way to programmatically skip this step please post a solution.


                        Using WPDM might offer more predictable file results but that requires database administration with checking out and checking in files.


                        In the end how SolidWorks opens a file is as clear as mud.





                          • Re: The Mysteries of External References
                            Bill Florac


                            Yes, if fact that does work. I have a script that runs outside of solidworks that sets the "Referenced Documents" setting, Opens up every assembly in the folder saves it and then resets the Referenced Documents to its original value. The SW documentation does put this location above others and that seems to work. Again, it is just an extra step that, because there is no way to detect this, you have to run on EVERY assembly right or wrong.




                        • Re: The Mysteries of External References
                          Shawn Wolters


                               We have seen this issue, and have created a work around...


                               In the past we would have a checker copy down an assembly and its parts from the network. (the whole folder) He would then open up his local file so he could review the assembly. As of 2014 or so it would open some of the files on his local and some off the network. This is an issue for us because the designer would be working on the network version and if he did not have it open before the checker it would be read only. annoying!


                               We now have the checker pack and go the assembly locally. Using SolidWorks Pack and go. Its a little more time consuming for him but he can add a prefix or what not. I understand it is a little different than your situation but hope it helps.


                            • Re: The Mysteries of External References
                              Bill Florac



                              We tested the Pack and Go and found that it was only 100% successful was if had the "Pack and Go" to put the files into a zip file. We can than copy the assembly files out of the zip file, overwriting the original files and all is fixed (but time consuming on large assemblies). Using "Pack and Go" to a folder worked sometimes but not always.



                                • Re: The Mysteries of External References
                                  Shawn Wolters



                                  This is good info to know. We have not seen this but I will sure let my team know to keep an eye out for this.



                                    • Re: The Mysteries of External References
                                      Alexey Groutso

                                      Hi Everyone,


                                      It almost seems to me like SolidWorks is trying to push people towards using EPDM. We've recently installed 2014 on our systems and this open search path issue is causing a lot of problems. We usually copy files from a network drive to work in our local drives and since it always looks back to network location to find the files nothing can be worked on smoothly as before.


                                      I am looking through api to find a way to bring things back to normal but for now the quickest and the most straight forward way I've found with fixing the issue is to this:

                                      • Copy files from network to local drive
                                      • DISABLE network adapter (unplug from network)
                                      • Open top assembly (you will get toolbox errors if your toolbox was on network drive, you can ignore it)
                                      • Save top assembly as all references now point to current project folder
                                      • Close assembly
                                      • ENABLE network adapter (plug back to network)
                                      • Open top assembly (all files are now taken from current folder and toolbox components are loaded)
                                      • Save file and you are ready to work on it.


                                      Keep in mind this solution will not work if you are coping from a local to another local folder, only renaming will kill the link in that case.


                                      This is stupid, but so far it works. I got absolutely no idea why SolidWorks decided to change this opening structure, it's like pre-2012 toolbox all over again. Hopefully the problem will be "magically" fixed in the next release for us all to buy.

                                  • Re: The Mysteries of External References
                                    Darryl Daniel

                                    We experience this exact same problem and it is maddening.  It has caused many critical errors where we fixed geometry, only to find out we fixed it on a network directory instead of our local copy.  I think the problem with the pack-and-go approach is that if you are using the PDM Vault (like we do 100% of the time) you lose version control....i.e. it resets each time you do the pack-and-go.  For now, we are just being very careful to check references every time we open up the top-level assembly.  It is ridiculous.  This should be fixed.

                                  • Re: The Mysteries of External References
                                    John Carlson

                                    We are having the same issues too.  It seemed to start about SolidWorks 2013.  SPR 770733 was created by us and supposedly fixed in 2015 SP 1 but the issues remain.


                                    In our case, we have nearly the opposite problem.  When a document is ready released the drawing and all the required files are moved to a release location.  When we open the drawings / assemblies from the release location we expect all the components to come from the release location but some (seemed to be older sub-assemblies and components) preferentially grabbed files from the original (source) folder (the engineer's folder).


                                    Earlier this year I finally wrote a macro to latch onto the FileOpenPreNotify event handler and set the reference folder.  This worked ... kind of.  I wanted to reset the reference folder location after the file loaded but there are a lot of scenarios where the FileOpenPostNotify event doesn't fire or at least doesn't fire in a timely fashion.  As a result the list of reference folders kept getting longer because it was never reset.


                                    I'm now re-writing the macro to respond ReferencedFilePreNotify event.  Specifically, I get the filename SolidWorks wants to load and then use OpenDoc6 to load the reference from the correct path (as I define it) into memory.  At that point, SolidWorks has to use the file in memory (unfortunately this logic defeats loading assemblies lightweight)


                                    Final comments:  When we discussed this issue with our VAR we were told to pack n' go everything and that does work.  Unfortunately, when our documents are moved to the release location it is via a program that decides were the files are placed (specifically, it's controlled by our corporate level document control system)

                                      • Re: The Mysteries of External References
                                        Ross Hazelwood

                                        The key to external references is to understand the search paths.

                                        Internal to the assembly or drawing, Solidworks has a list of referenced files

                                        - you can see these using the File-Find references command, and they show as absolute pathnames.

                                        - If you copy the assembly or drawing to another place, then this internal list is unchanged (even if you have also copied the reference parts so:

                                            If you open the copied file into an new solidworks window, it  will load related parts from the original location.  Only if it cannot find the file in the original location, then it will look elsewhere, and there is an order listed in the Solidworks documentation for search paths, but the current directory is at the bottom of the list .  This is why renaming the original directory does stop loading of original parts.


                                        But if you have any part of the same name (but from a different directory already open) then Solidworks will automatically use it instead and there is no warning given, because it is assuming you knew what you were doing.


                                        My recommendation when copying files out to a contractor to work offsite is that you use copy tree, which then replaces all the internal references so they point to the newly copied files, and makes sure that he has a full set of files with none missing.  I would then set all of these files to readonly so that the contractor cannot change them, and require the contractor to use save as with a prefix in front for any file he wishes to change. 


                                        We use the readonly rule, because simple things like opening a part and changing configuration causes the part to change - so on saving of an assembly the part will be resaved with a new modified date meaning you will never know if it was a geometry change or not. 


                                        So making initial files read-only means that you can reliably identify which files has been changed when you come to reimport them, and only import the changed versions.  But remember that you will have to update the contractor references to point back to your released part drawings. 


                                        Easiest way to do it will be to open the original assembly, then open the contractor assembly (which will then use the parts already in session, and changed ones have prefix names).  Now you can close the original assembly, and resave the contractor parts which had a different name back over the top of the originals, but you only have to check and deal to any parts with the contractor prefix, so the job is much shorter than before.  Final check of course is checking with file-find references, but that is even easier with EPDM because we have it set to error if parts are referenced outside of the vault.

                                          • Re: The Mysteries of External References
                                            Bill Florac

                                            Ross. You make some good points. Note that the File-File references is NOT correct unless all components are fully resolved. This becomes difficult with large assemblies with nested sub-assemblies.  I often work on assemblies with 600 parts and 10 layers deed in assemblies. Having to resolve all of these can really take some time.


                                            There is an internal reference number that SW uses and updates if there was an actual change to the part. I use it with a file internal maintenance tool we have. Maybe someday SW will expose it. Else, your read-only method is a good choice. It would be nice if Windows allowed for a check box in a column that you could see and change the read-only property quickly.


                                            As mentioned above, I have a macro that sets the file location "Referenced Documents" to a give path. If you set this, it will ALWAYS look there before anything else.  I'm not sure why SW does not give us the option "For assemblies, only look in same folder for components".  Of course if you are using PDM, you don't want this as you will get all referenced documents from the vault. It just makes exporting and sending them to someone more complicated. Which, is why I used the zip method also mentioned above.



                                        • Re: The Mysteries of External References
                                          Amen Allah Jlili

                                          This is the reason why PDMs exists. The suppressed or lightweight components are not having their references updated when they're copied locally. I think the problem is is coming from this:

                                          NOTE: For assemblies containing suppressed or lightweight components, file references (return value from this method) point to the as-saved component reference because the actual component has not been loaded into memory. Because the suppressed and lightweight components have not actually been loaded, the current search criteria has not been applied to update the file references. Setting Searchflag to True vs. false, causes this method to apply the current search criteria rules to locate the particular reference and may result in a different return value. Likewise, unsuppressing or resolving these components causes the current search criteria to be applied and updates the assembly's component references in memory, if necessary.

                                          2013 SOLIDWORKS API Help - GetDependencies2 Method (IModelDoc2)

                                          In general suppressed components represent the last saved state of the original modeldoc.
                                          I wonder if 2012 SOLIDWORKS API Help - GetCurrentWorkingDirectory Method (ISldWorks)  could help you.