File paths get screwed up

In your options there are two settings that control how SW finds a file.

1) Search External References 2) In file locations, the Referenced files location.

If 1 is checked and 2 points to the new location you will probably find that the file will then be found. On the other hand, if 1 is unchecked and you tell SW where to find the file and save that change you should have no problem.

TOP

TOP,

"1" was checked, but there are no folders listed for "2", so I presume this effectively negates having "1" checked.

I've read the help files on "Search routine for referenced documents", but I still don't understand how having manually browsed for the correct file/location and then saved the assembly, SWX can still try to look for it in a folder that I can't see because it's on somebodys local h/disk.

It's as if the assembly file still contains the history of where this part was once saved, and it won't forget it!

John H

John, If there are sub-assemblies that refer to documents in other locations, then you will have to open each one and rebuild them, to update correctly.

Am I correct, in that these documents, were originally on another person's hard drive or were at a different location? If so, the pack and go system should be used, (file, find references), you can not just copy and paste.

I wonder if it's because the assembly is being opened lightweight, so that although it's prompting me to find the new file location, it doesn't actually save this info for the sub-assys which are lightweight.

The original assy, sub-assy and parts are all on a network drive. I've opened the assy and "saved as" a new assy in a different folder on the same drive. Opening the assy subsequently, I get the "can't find component file" errors, so I browse to the right location and save the assy again - but this doesn't make the changes stick.

Maybe I need to have everything resolved?

John H

In my experience, yes, everything needs to be resolved. Especially subassemblies. And sub-subassemblies. Etc., etc.. At least until you get to the one that contains the bad pointer. If you know the file(s) that SW is having problems with (and you should, the error message gives you the filename), find it in the assembly structure, and make sure that the assembly that contains it is resolved (and open, obviously), and then save that assembly. This may or may not fix the problem. If there are other files in the same location on the hard drive, but in other assemblies, they'll need to be done also. They'll may suddenly appear as new error messages once the first one is fixed (depends upon the order you open the assemblies). Once SW finds one file in a folder, with your help, it'll look there for the rest of the files.

Thanks for everyone's suggestions. I'll try resolving everything and see if it sorts it.

John H

What I do when running out of hair to pull is click the 'References...' button before opening the top level assembly file and examine the list for anything wrong. Usually I'll find the offending file that way, then I go fix that file or edit the list for the new (correct) file location.

If there are hundreds of file references I'll do the 'File> Find References' then copy the list to a text file, then open in ti Excel and sort by folders.

2¢ wc

John H wrote:

If 1 is checked then I think it will make a difference in how SW searches. You can put paths and get SW to be very selective about what it finds. But nine times out of ten having 1 checked results in unepected results if you are not careful. Also remember that with 1 checked and nothing in 2 SW may go to the last director you listed, even if it was with Explorer and not in SW. That can cause some very unexpected results. I have always wished for SW to provide some feed back as to where it is getting a file.

TOP

Maybe that is what is happening. I tried on Friday having everything resolved and saved. Today (Monday) it gave me the same message yet again about "can't find file". I let it finish opening the document and then immediately closed it without saving. I then selected it for opening again and picked the "file references" option button on the file/open dialogue box, and guess what, all the references were pointing to the right locations, none of which is in the location SWX is looking.. So why they hell does it want to look somewhere else??

John H

I had a similar problem where a sketch point in the offending part some referencing another part(external reference). As I recall it was in a part that was created in an assembly. When I do that I try to delete any relations to any other file, sometimes one slips past.

maybe something top look for...

2¢