File Refs in the parent file, opened by full path or just file name?

[bnemec]

Solid Edge and Solidworks both appear to open reference files only by the file name stored in the parent file, NOT by the full path. For the life of me I cannot figure out how this is a good idea. What a mess this creates. Side note, I understand duplicate file names are bad bad bad, but letting the software silently choose which one to use causes much grief.

Maybe a thread on other users experience of CAD opening a ref file by the name but in the wrong path. Add in PDM systems if you like or migrating from one to another. Maybe some hints on how to adjust the CAD software to only open the full path that is stored in the parent file.

Thanks.

[matt]

No, it's SOOOO simple. All you have to do is memorize the 13 different places and conditions where SolidWorks looks for the files. As long as you can follow these steps, you'll never get the wrong file! I'm sure Solid Edge uses something similar.

(borrowed from the SW help)

1. Uses any open document with the same name.
   If p2.sldprt is in another open document, SOLIDWORKS uses this version of p2.sldprt.
2. Searches the first path that you specify in the Folders list in the File Locations Options dialog box.
   You must select the Search file locations for external references check box in the External References Options dialog box or else SOLIDWORKS ignores the paths that you specify.
   D:\aa\bb\p2.sldprt
3. Searches the path in Step 2 plus the last folder in the path where the referenced document was last saved.
   D:\aa\bb\xx\p2.sldprt
4. Searches the path in Step 2 plus the last two folders in the path where the referenced document was last saved.
   D:\aa\bb\yy\xx\p2.sldprt
5. Repeats Step 4 until the full original path has been appended to the path in Step 2.
   This concept of adding one folder at a time from the full path will be called "recursive searching" in the following steps.
   D:\aa\bb\zz\yy\xx\p2.sldprt
6. Recursively searches the first path in the Folders list, then recursively searches the path where the referenced document was last saved.
   
   
   D:\aa\xx\p2.sldprt
   
   D:\aa\yy\xx\p2.sldprt
   
   D:\aa\zz\yy\xx\p2.sldprt
   
   D:\xx\p2.sldprt
   
   D:\yy\xx\p2.sldprt
   
   D:\zz\yy\xx\p2.sldprt
7. Repeats Steps 2 through 6 for the other folders in the Folders list.
   
   
   E:\cc\dd\p2.sldprt
   
   E:\cc\dd\xx\p2.sldprt
   
   E:\cc\dd\yy\xx\p2.sldprt
   
   E:\cc\dd\zz\yy\xx\p2.sldprt
   
   E:\cc\xx\p2.sldprt
   
   E:\cc\yy\xx\p2.sldprt
   
   E:\cc\zz\yy\xx\p2.sldprt
   
   E:\xx\p2.sldprt
   
   E:\yy\xx\p2.sldprt
   
   E:\zz\yy\xx\p2.sldprt
8. Searches the path of the active document, then recursively searches the path where the referenced document was last saved.
   
   
   D:\ss\tt\p2.sldprt
   
   D:\ss\tt\xx\p2.sldprt
   
   D:\ss\tt\yy\xx\p2.sldprt
   
   D:\ss\tt\zz\yy\xx\p2.sldprt
   
   D:\ss\xx\p2.sldprt
   
   D:\ss\yy\xx\p2.sldprt
   
   D:\ss\zz\yy\xx\p2.sldprt
   
   D:\xx\p2.sldprt
   
   D:\yy\xx\p2.sldprt
   
   D:\zz\yy\xx\p2.sldprt
9. Searches the path where you last opened a document, then recursively searches the path where the referenced document was last saved.
   In most cases, the path of the active document and the path where you last opened a document are the same.
   
   The two paths are different if you click File > Open to open one document, then drag and drop an assembly from Windows Explorer into that document. The path of the active document is the path from Windows Explorer and the path where you last opened a document is the path from File > Open .
   
   
   same as Step 8
10. Searches the path where the software last found a referenced document.
    
    
    C:\qq\p2.sldprt
    
    This is the location of p1.sldprt.
11. Searches the full path where the document was last saved without a drive designation.
    
    
    This is useful if you save a part with a UNC path such as \\machine\folder\p2.sldprt.
12. Searches the full path where the document was last saved with its original drive designation.
    C:\zz\yy\xx\p2.sldprt
13. Allows you to browse for the document yourself.

[bnemec]

No, it's SOOOO simple. All you have to do is memorize the 13 different places and conditions where SolidWorks looks for the files. As long as you can follow these steps, you'll never get the wrong file! I'm sure Solid Edge uses something similar.

(borrowed from the SW help)

1. Uses any open document with the same name.
   If p2.sldprt is in another open document, SOLIDWORKS uses this version of p2.sldprt.
2. Searches the first path that you specify in the Folders list in the File Locations Options dialog box.
   You must select the Search file locations for external references check box in the External References Options dialog box or else SOLIDWORKS ignores the paths that you specify.
   D:\aa\bb\p2.sldprt
3. Searches the path in Step 2 plus the last folder in the path where the referenced document was last saved.
   D:\aa\bb\xx\p2.sldprt
4. Searches the path in Step 2 plus the last two folders in the path where the referenced document was last saved.
   D:\aa\bb\yy\xx\p2.sldprt
5. Repeats Step 4 until the full original path has been appended to the path in Step 2.
   This concept of adding one folder at a time from the full path will be called "recursive searching" in the following steps.
   D:\aa\bb\zz\yy\xx\p2.sldprt
6. Recursively searches the first path in the Folders list, then recursively searches the path where the referenced document was last saved.
   
   
   D:\aa\xx\p2.sldprt
   
   D:\aa\yy\xx\p2.sldprt
   
   D:\aa\zz\yy\xx\p2.sldprt
   
   D:\xx\p2.sldprt
   
   D:\yy\xx\p2.sldprt
   
   D:\zz\yy\xx\p2.sldprt
7. Repeats Steps 2 through 6 for the other folders in the Folders list.
   
   
   E:\cc\dd\p2.sldprt
   
   E:\cc\dd\xx\p2.sldprt
   
   E:\cc\dd\yy\xx\p2.sldprt
   
   E:\cc\dd\zz\yy\xx\p2.sldprt
   
   E:\cc\xx\p2.sldprt
   
   E:\cc\yy\xx\p2.sldprt
   
   E:\cc\zz\yy\xx\p2.sldprt
   
   E:\xx\p2.sldprt
   
   E:\yy\xx\p2.sldprt
   
   E:\zz\yy\xx\p2.sldprt
8. Searches the path of the active document, then recursively searches the path where the referenced document was last saved.
   
   
   D:\ss\tt\p2.sldprt
   
   D:\ss\tt\xx\p2.sldprt
   
   D:\ss\tt\yy\xx\p2.sldprt
   
   D:\ss\tt\zz\yy\xx\p2.sldprt
   
   D:\ss\xx\p2.sldprt
   
   D:\ss\yy\xx\p2.sldprt
   
   D:\ss\zz\yy\xx\p2.sldprt
   
   D:\xx\p2.sldprt
   
   D:\yy\xx\p2.sldprt
   
   D:\zz\yy\xx\p2.sldprt
9. Searches the path where you last opened a document, then recursively searches the path where the referenced document was last saved.
   In most cases, the path of the active document and the path where you last opened a document are the same.
   
   The two paths are different if you click File > Open to open one document, then drag and drop an assembly from Windows Explorer into that document. The path of the active document is the path from Windows Explorer and the path where you last opened a document is the path from File > Open .
   
   
   same as Step 8
10. Searches the path where the software last found a referenced document.
    
    
    C:\qq\p2.sldprt
    
    This is the location of p1.sldprt.
11. Searches the full path where the document was last saved without a drive designation.
    
    
    This is useful if you save a part with a UNC path such as \\machine\folder\p2.sldprt.
12. Searches the full path where the document was last saved with its original drive designation.
    C:\zz\yy\xx\p2.sldprt
13. Allows you to browse for the document yourself.

Alright, we need a downvote/thumb down button. Note no purple font.
I've had it to my eye balls with what you've just copy pasted!

Where in that ridiculous list does it say:

99. If all else fails, try using the full path as saved in the parent file, you know, just incase they were serious about wanting the next person to use the same thing, maybe.

[matt]

Alright, we need a downvote/thumb down button. Note no purple font.
I've had it to my eye balls with what you've just copy pasted!

Where in that ridiculous list does it say:

99. If all else fails, try using the full path as saved in the parent file, you know, just incase they were serious about wanting the next person to use the same thing, maybe.

Well, the full path is actually in there, but - and you're gonna LOVE this - it's the next to last option. Not 99, but 12/13. It's a crazy system, which is part of the reason you can't screw up your file management or make duplicate files.

One of the things I like about Onshape is that this is never a problem. At least that's my understanding, not being a real user.

[jcapriotti]

Get PDM, pretty much eliminates the file path issues. Even if I were a one man operation I'd use it.

[bnemec]

Get PDM, pretty eliminates the file path issues. Even if I were a one man operation I'd use it.

We have PDM which has just been fanning the flames! Migrated data from network shares where the files still are. Nearly impossible to get CAD to only look in PDM.
Also, we've migrated to a new vault and there were some (most) of the users that just ignored my instructions of removing old vault view (which still has many files in cache even though they cannot log in) but if Solidworks thinks that's a good place to go there's no stopping it, even when the user just did a get latest on the parent file and has all the references in that cache. I figured out how to run a script on remote computers that forcefully removes Vault Views so that has helped. But I need to keep a view of the old vault for the sake of looking up history, I get bombarded with the Log in dialog from the old vault when opening assembly from new vault. I know the assembly was checked in with good refs in this case.

Solid Edge does the same thing, looks a bit different but about the same behavior. I can categorically state that is was much simpler to deal with this behavior before PDM.

[bnemec]

Alright, we need a downvote/thumb down button. Note no purple font.
I've had it to my eye balls with what you've just copy pasted!

Where in that ridiculous list does it say:

99. If all else fails, try using the full path as saved in the parent file, you know, just incase they were serious about wanting the next person to use the same thing, maybe.

Well, the full path is actually in there, but - and you're gonna LOVE this - it's the next to last option. Not 99, but 12/13. It's a crazy system, which is part of the reason you can't screw up your file management or make duplicate files.

One of the things I like about Onshape is that this is never a problem. At least that's my understanding, not being a real user.

edit, Matt, did you forget to color the "and you're gonna LOVE this" ?

12. "Where it was lasted saved" what does that mean? Is that their way of saying "according to the full path in the parent file"? or Where it was lasted saved in the scope of the PC I am currently on.

In Solid Edge the references were visible when the file was opened with a compound file explorer, they are listed in Jsites... I wrote a parser so I could index our references for the sake of fast where used searches. I think at ST9 they made that info public with some .dlls that windows indexing service can use (BiDM mechanism I think)
In Solidworks the only place I can find to reliably get what the full path is in the parent file is using Pack and Go. That appears to show me the unmolested path as it was saved in the parent file rather than where SW is going to try to find it.

[matt]

edit, Matt, did you forget to color the "and you're gonna LOVE this" ?

12. "Where it was lasted saved" what does that mean? Is that their way of saying "according to the full path in the parent file"? or Where it was lasted saved in the scope of the PC I am currently on.

In Solid Edge the references were visible when the file was opened with a compound file explorer, they are listed in Jsites... I wrote a parser so I could index our references for the sake of fast where used searches. I think at ST9 they made that info public with some .dlls that windows indexing service can use (BiDM mechanism I think)
In Solidworks the only place I can find to reliably get what the full path is in the parent file is using Pack and Go. That appears to show me the unmolested path as it was saved in the parent file rather than where SW is going to try to find it.

Yes, of course, I meant to color it sarcastic. Sorry, I've fixed that oversight...

I think "last saved location" has to mean last place that the assembly knew that the part was saved. It couldn't know anything about the part being saved when the assembly wasn't open, which is part of the problem with file management when you have referenced files.

The database method is so much more solid.

[bnemec]

Yes, of course, I meant to color it sarcastic. Sorry, I've fixed that oversight...


The database method is so much more solid.

No worries!

Absolutely!
I just wish Solidworks would listen to where PDM says to get the refs from. If I understand correctly, PDM updates the refs in the parent file when that file is copied to local cache. That is how PDM can update all the files if a ref file is moved or renamed for some reason, it doesn't actually update all the files at that time, just the reference records in SQL then updates the file when it is downloaded to local cache?

[Frederick_Law]

In any multi-user environment, ALL users NEED to use SAME folder structure.
Same drive letter (local and mapped network drive).
All you need is one user don't follow this rule to have never ending file referencing.
This apply to PDM and not.
Also apply if software remember full path or not.

[Glenn Schroeder]

I know this will be considered sacrilege by most users, but I have multiple files with the same name. I've been doing it for years, and never had an issue with it. No PDM, by the way.

1. When I start a new project, where I'm not sure what the final design will look like (which is almost all of them), I have a sub-folder with the current date as the folder name.

2. All new SW files that are specific to that project are saved in that folder. I do not have separate folders for different file types. When we first started with Solidworks Parts, Assemblies, and Drawings all had a separate folder. I don't know who told them to do it that way, but it was a nightmare. (I was still on the construction crew when that happened.)

3. When I have a design change I either copy the files to a new folder (again, with the current date as the folder name), or do a Pack and Go to a new folder. I rarely change any file names as part of this process.

4. When the design is finished I Pack and Go the top level file (which is almost always a Drawing) into the Drafting folder for that project, which leaves behind any files that are no longer used. Then I open that new Drawing, and while it's open I delete all the no longer needed folders and their contents. By having the Drawing open I make sure that I don't delete anything I need, but it's never been an issue.

The only reason this works is that all project specific files are in the same folder, and when I open a Drawing or Assembly the software will first look for, and use, files in the same folder as the Drawing or Assembly. Right or wrong, that's how it works, and I'm a big believer in accepting and working with things I can't change instead of wasting energy fighting against them.

[jcapriotti]

Glenn, I think you can get away with that if you are working on projects that never cross, they are standalone and isolated. But if ever you need to open two assemblies from two different projects that both contain files with the same name, the first one you open wins, the seconds loads files in memory first.

Before PDM we had to constantly drive home to the engineers that when you copy Released files you need to prefix the file names with the project/eco number. Of course that led to them using Pack n Go to copy everything with a prefix which in turn led to unnecessary copies of files, that no longer update. Which led to questions like "How do I get the latest updates to my file set".

[bnemec]

In any multi-user environment, ALL users NEED to use SAME folder structure.
Same drive letter (local and mapped network drive).
All you need is one user don't follow this rule to have never ending file referencing.
This apply to PDM and not.
Also apply if software remember full path or not.

Check, done.
It's not that the software cannot find reference files, the problem is that it's looking for the reference files in the wrong places and therefore using the wrong files (sometimes)

[berg_lauritz]

Glenn, I think you can get away with that if you are working on projects that never cross, they are standalone and isolated. But if ever you need to open two assemblies from two different projects that both contain files with the same name, the first one you open wins, the seconds loads files in memory first.

Before PDM we had to constantly drive home to the engineers that when you copy Released files you need to prefix the file names with the project/eco number. Of course that led to them using Pack n Go to copy everything with a prefix which in turn led to unnecessary copies of files, that no longer update. Which led to questions like "How do I get the latest updates to my file set".

That's what we are doing right now.
I rename every single part, that I modify though - which means, that sometimes after re-linking the part I have to do the work twice (add a cfg etc.).
It's still faster for bigger changes, because working on the network is such a time saver. There was a talk on the World2021 which showed a decrease in rebuild/save/open time of more than 50%. An insane number for large assemblies.

[jcapriotti]

It's pretty simple, the software stores the file reference's filename and path in the assembly/drawing. If you rename a file or move it then you have a problem. People are just used to renaming files and moving files/folders however they feel like without understanding the implications. Not sure how any software can handle this better working in a file system, unless it replaces that filesystem with some sort of PDM like feature that monitors every file/folder operations and updates the file references.

Try linking some Excel and Word files together and you have the same problem, only worse since there are less tool to see and work with those links.

[jcapriotti]

I rename every single part, that I modify though - which means, that sometimes after re-linking the part I have to do the work twice (add a cfg etc.).

Worse when our users copy everything, not just parts they want to change. Unfortunately they are in hurry and Pack n Go offers the path of least resistance which is to copy everything.

[Glenn Schroeder]

Glenn, I think you can get away with that if you are working on projects that never cross, they are standalone and isolated. But if ever you need to open two assemblies from two different projects that both contain files with the same name, the first one you open wins, the seconds loads files in memory first.

Before PDM we had to constantly drive home to the engineers that when you copy Released files you need to prefix the file names with the project/eco number. Of course that led to them using Pack n Go to copy everything with a prefix which in turn led to unnecessary copies of files, that no longer update. Which led to questions like "How do I get the latest updates to my file set".

You're right, of course. My projects are stand-alone. Many of them use the same Parts and sub-assemblies, but those shared files are in a separate location, and not copied to the project specific folders. Occasionally we will need to modify one of those Parts for a specific project, but in those cases I copy it to the project specific folder and re-name it before making any edits or inserting it into an Assembly.

I just wanted to make the point that having files with the same name isn't problematic in all situations.

[berg_lauritz]

I rename every single part, that I modify though - which means, that sometimes after re-linking the part I have to do the work twice (add a cfg etc.).

Worse when our users copy everything, not just parts they want to change. Unfortunately they are in hurry and Pack n Go offers the path of least resistance which is to copy everything.

Yes, I pack&go everything too, because I want to work locally.
Later on I re-link the unchanged parts back manually to our standard network folders.

it is 'fairly' easy to do luckily, just remove the extension & change the folder & you're done.
Every part that I modify, I rename to modified_xxxxxx, thus I know what I need to change on the network drive (or make new part # for that):

InkedScreenshot 2021-03-12 104335_LI.jpg

[Merovingien]

maybe this thread suits better in the "Solidworks place" ?

[jcapriotti]

Yes, I pack&go everything too, because I want to work locally.
Later on I re-link the unchanged parts back manually to our standard network folders.

This is where PDM helps, you are always working locally with some minimal traffic to the DB checking to make sure your local copies are up to date.

[Ry-guy]

Maybe a thread on other users experience of CAD opening a ref file by the name but in the wrong path. Add in PDM systems if you like or migrating from one to another. Maybe some hints on how to adjust the CAD software to only open the full path that is stored in the parent file.

It's been my experience that some software actully create unique IDs assigned to every part that is created. Then the user has the ability to:

• Load from search directories..
  Load As Saved
  From Folder

This tells you how the system is going to find files. You then can set behavior of the load. What to do when I find a file who's name matches.

• Allow Replacement
  Or Fail to load

This is defined by the matching the UIDs. If they original and new file have the same UID the software loads the file. If they don't match it will not load.

This ensure yo uare not loading Block.prt in Project1 folder instead of the Block.prt in Project2 folder.

This just goes to show that if SW or other CAD tools don't think of this stuff in advance..then you have to come up with some other "work around"..which SW is notorious for!

[matt]

SolidWorks has internal IDs. It can tell the difference between a copy of Part1 and a part created and named Part1 independently, but it doesn't use that ID for finding files, just telling you if the file you found is definitely the wrong one. It can't tell you if it's the wrong copy, just that it was never really associated with your referencing document.

All of this is manageable manually, but you have to be really disciplined and absolutely understand what is going on. PDM is the best way, but some of the new CAD packages have baked-in PDM, so all of this very Windowsy hunting around for referenced files becomes a thing of the past.

The problem is that there is no single CAD product that gets everything right:

- platform (cloud vs desktop)
- data management (files vs db)
- modeling (history vs direct vs subd)
- interface.

I guess it's too much to ask.

[jcapriotti]

SolidWorks has internal IDs. It can tell the difference between a copy of Part1 and a part created and named Part1 independently, but it doesn't use that ID for finding files, just telling you if the file you found is definitely the wrong one. It can't tell you if it's the wrong copy, just that it was never really associated with your referencing document.

Finding files by internal ID would probably be a big performance hit. The assembly would have to scan file's internal information and I imagine this is much slower than just finding the file via filename.

All of this is manageable manually, but you have to be really disciplined and absolutely understand what is going on. PDM is the best way, but some of the new CAD packages have baked-in PDM, so all of this very Windowsy hunting around for referenced files becomes a thing of the past.

Inventor has a built in project file tool that looks good at first glance. You can't just rename files in the project tool (which would make sense), you have to open the file in the separate Design Assistant which kind of resembles SolidWorks Explorer. The "Rename" was greyed out for some reason and the online help made it look way more complicated than it should be. Renaming them in Windows Explorer broke the links just like SolidWorks.

[MJuric]

Solid Edge and Solidworks both appear to open reference files only by the file name stored in the parent file, NOT by the full path. For the life of me I cannot figure out how this is a good idea. What a mess this creates. Side note, I understand duplicate file names are bad bad bad, but letting the software silently choose which one to use causes much grief.

Maybe a thread on other users experience of CAD opening a ref file by the name but in the wrong path. Add in PDM systems if you like or migrating from one to another. Maybe some hints on how to adjust the CAD software to only open the full path that is stored in the parent file.

Thanks.

This is one of the things that people that move from SW to IV HATE and one of the things that people moving from IV to SW go "HOLY !@!@$ are you serious....it just decides what file it wants to open?!"

I can't count the times that people I know did some work on IV and came back saying "Man that software sucks" and 99% of the time it was because they did not grasp the concept that IV works in well organized and defined projects. You can't just willy nilly add in files from anywhere with any name or any file that "Seems like it will work". Either the file is in the defined directories and the file matches....or it tells you you're an idiot :-)

[bnemec]

Solid Edge and Solidworks both appear to open reference files only by the file name stored in the parent file, NOT by the full path. For the life of me I cannot figure out how this is a good idea. What a mess this creates. Side note, I understand duplicate file names are bad bad bad, but letting the software silently choose which one to use causes much grief.

Maybe a thread on other users experience of CAD opening a ref file by the name but in the wrong path. Add in PDM systems if you like or migrating from one to another. Maybe some hints on how to adjust the CAD software to only open the full path that is stored in the parent file.

Thanks.

This is one of the things that people that move from SW to IV HATE and one of the things that people moving from IV to SW go "HOLY !@!@$ are you serious....it just decides what file it wants to open?!"

I can't count the times that people I know did some work on IV and came back saying "Man that software sucks" and 99% of the time it was because they did not grasp the concept that IV works in well organized and defined projects. You can't just willy nilly add in files from anywhere with any name or any file that "Seems like it will work". Either the file is in the defined directories and the file matches....or it tells you you're an idiot :-)

I think I'm on the same page. I'd rather be informed that I'm an idiot so I can fix it than have the software think for me and find a file it thinks is what I want. I would like a "tell me I'm an idiot" file reference setting something like "open the path referenced in the parent file or mark the ref as missing" And be transparent as to where the reference is supposed to be. Instead the default (and non configurable) behavior is to find a file, assume it's correct and update the references when the parent file is saved.

You mentioned "well organized and defined projects." We cannot keep files in "Project" directories because our files are used all over the place, across >many< projects so it would be nonsensical to have files in Project Directory structure. Although this seems to be an assumed industry standard based on how the program searches for references also, behind the scenes in PDM directories are called Projects. Anyway, when we started with PDM we considered not having a directory structure for the general product data (files that would share a workflow and data card) just dump them all in one directory, after all the folder structure only exists on the clients cache, the files are actually archived in secret hexadecimal folder structure on the archive. But since there is still some browsing (even if just in loading the open or save file dialogs) we wanted to keep <~2000 files per directory; so it is broken down by file name.

Just me I guess. It sounds like most users feel that the software should fix broken refs at all costs.

[MJuric]

Solid Edge and Solidworks both appear to open reference files only by the file name stored in the parent file, NOT by the full path. For the life of me I cannot figure out how this is a good idea. What a mess this creates. Side note, I understand duplicate file names are bad bad bad, but letting the software silently choose which one to use causes much grief.

Maybe a thread on other users experience of CAD opening a ref file by the name but in the wrong path. Add in PDM systems if you like or migrating from one to another. Maybe some hints on how to adjust the CAD software to only open the full path that is stored in the parent file.

Thanks.

This is one of the things that people that move from SW to IV HATE and one of the things that people moving from IV to SW go "HOLY !@!@$ are you serious....it just decides what file it wants to open?!"

I can't count the times that people I know did some work on IV and came back saying "Man that software sucks" and 99% of the time it was because they did not grasp the concept that IV works in well organized and defined projects. You can't just willy nilly add in files from anywhere with any name or any file that "Seems like it will work". Either the file is in the defined directories and the file matches....or it tells you you're an idiot :-)

I think I'm on the same page. I'd rather be informed that I'm an idiot so I can fix it than have the software think for me and find a file it thinks is what I want. I would like a "tell me I'm an idiot" file reference setting something like "open the path referenced in the parent file or mark the ref as missing" And be transparent as to where the reference is supposed to be. Instead the default (and non configurable) behavior is to find a file, assume it's correct and update the references when the parent file is saved.

You mentioned "well organized and defined projects." We cannot keep files in "Project" directories because our files are used all over the place, across >many< projects so it would be nonsensical to have files in Project Directory structure. Although this seems to be an assumed industry standard based on how the program searches for references also, behind the scenes in PDM directories are called Projects. Anyway, when we started with PDM we considered not having a directory structure for the general product data (files that would share a workflow and data card) just dump them all in one directory, after all the folder structure only exists on the clients cache, the files are actually archived in secret hexadecimal folder structure on the archive. But since there is still some browsing (even if just in loading the open or save file dialogs) we wanted to keep <~2000 files per directory; so it is broken down by file name.

Just me I guess. It sounds like most users feel that the software should fix broken refs at all costs.

I've mentioned on the other forum that SW is unstable and buggy for two big reasons. It tries to be all things to all people and is willy nilly with it's file structure. These two things lead too all the massive inconsistencies you see and a plethora of things that you "Can do"....."But probably shouldn't", assuming you wanted a stable model.

I can say that IV is far more "Strict" in both aspects. It far less often will allow you to do something that later will end up with a complete and utter meltdown. It still allows things like that to happen, just far less often. More often than not you'll get the..."Yeah, nope...I'm not going to let you do something that stupid"

[Frederick_Law]

Since I use multiple versions, I need to be very careful on file reference.

After copying all the files to new location, I need to reference them so they don't open in old folder and save new version there.

After copying all files, I'll rename the original folder so SW can't find it.

Open assemblies, drawing and find all the missing links in new folder.
Check File Reference before save.

[jcapriotti]

I think I'm on the same page. I'd rather be informed that I'm an idiot so I can fix it than have the software think for me and find a file it thinks is what I want. I would like a "tell me I'm an idiot" file reference setting something like "open the path referenced in the parent file or mark the ref as missing" And be transparent as to where the reference is supposed to be. Instead the default (and non configurable) behavior is to find a file, assume it's correct and update the references when the parent file is saved.

I assume you mean working outside PDM as it won't allow duplicate filenames and thus it could (almost) never load the wrong file. The only weird exception I can think of would be if a user took it upon themselves to store some files outside PDM while working on files in PDM.

Before PDM, I spent years managing this manually on a network drive. This took adhering to a rigid process and a lot of training to end users on what not to do. We are like you, we don't have isolated projects but instead numerous products that share many components. In this environment without PDM you have to use the "File Locations/References" and it's search rules to manage files undergoing ECO changes thru a release cycle. In order for that to be effective you have to have a read-only folder structure that the users can't change.

Without the search paths defined, the software always looks where the reference was last located when the assy was saved, if it can't find it there, then it defaults to the same folder the assembly was opened from. The one caveat to this is that what's loaded in a memory always wins. If I have a part called "Bar" on my desktop and I open it, then I decide later to open an assembly from anywhere else and it contained a part with that name, the file in memory is used. The software does warn you that the internal ID does not match and defaults to suppressing it, however I notice that users often don't pay attention to it.....and they like to click that box to "Don't show again".

Just me I guess. It sounds like most users feel that the software should fix broken refs at all costs.

Users are lazy like that. They just want the software to work and not have to fiddle with where files are and what they are called. Training is the first key but the second key is forcing them to fix their mistakes, otherwise it never gets committed to memory.

"People will not change until the pain of not changing is greater."

[Frank_Oostendorp]

I think we missed the first lines:

Capture.JPG

Paths to referenced files are in parent documents. The search routine starts if the referenced file is not at the expected location, stated as "missing referenced document".

[jcapriotti]

Paths to referenced files are in parent documents. The search routine starts if the referenced file is not at the expected location, stated as "missing referenced document".

True, except if you have "Search external references in" checked and you have paths defined. It will search there first and go thru that recursive search routine. That failing it will search where the save path in the assy says it was last located.

[SPerman]

I didn't read the whole thread, but be warned, pack and go can fail, and still point to the original file location. My VAR told my my file structure was too complicated.

[bnemec]

Paths to referenced files are in parent documents. The search routine starts if the referenced file is not at the expected location, stated as "missing referenced document".

True, except if you have "Search external references in" checked and you have paths defined. It will search there first and go thru that recursive search routine. That failing it will search where the save path in the assy says it was last located.

I'm relatively new to Solidworks and there are many intricacies that I have yet to find. If I'm not mistaken I have this set the way you suggest so that SW should first use the path stored in the parent file?

image.png

Then the next problem is all the other SW installations may have this set differently. Before PDM the file was either on a network share that we all had access to or it was on the saving computer's local drive(s), so either the opening computer had it or not and it was crystal clear when the parent was looking for file not on network share. I'm not saying that was better or PDM is worse, its just that the "what the heck is going on?" question becomes harder to answer. PDM has added a couple layers of complexity from what I can understand several things can happen that many users don't notice.

• on check in of the parent, if a ref is not in the vault PDM will just ignore the reference, like it was never there
  if the parent file is ref a local file but that name also exists in vault PDM will resolve the ref to the filename that's already in the vault at check in (I think)
  
  When importing a large assembly (x_t and 3D interconnect off) there are a LOT of files saved in a short time, if we have found that if this is done in a vault location while "On Line" PDM will sometimes miss a bunch of these files and they remain as <Local File>. That is one potential reason why there may be duplicate filenames, since these are dropped in the same location as the imported file they may be in a not ideal place. Then I found out that even though PDM is set to delete local files, (which only applies to read only files) does not delete these files because they are not read only as they were never added to the vault so PDM didn't set the read only file flag. So the user unwittingly has duplicate file names that are not in the vault but the path looks like they're in the vault. There are no refs to them in PDM because they are not in the vault, other uses do not see them because they are local only and the person on that computer doesn't realize what's going on.
  
  Next, when another user opens the parent assembly SW will do it's best to find that file, if it can (unfortunate) and the user fails to notice the dialog that disappears in 10 seconds that SW is using some other file now they are unaware of what's going on and think I'm going to yell at them for not getting files as referenced.

I could go on but I'm digressing.

[jcapriotti]

I'm relatively new to Solidworks and there are many intricacies that I have yet to find. If I'm not mistaken I have this set the way you suggest so that SW should first use the path stored in the parent file?

Yes, except what's already loaded in memory is always number 1.....PDM or not. This bites users more than you think if they are copying stuff around but not renaming it.

Then the next problem is all the other SW installations may have this set differently. Before PDM the file was either on a network share that we all had access to or it was on the saving computer's local drive(s), so either the opening computer had it or not and it was crystal clear when the parent was looking for file not on network share. I'm not saying that was better or PDM is worse, its just that the "what the heck is going on?" question becomes harder to answer. PDM has added a couple layers of complexity from what I can understand several things can happen that many users don't notice.

• on check in of the parent, if a ref is not in the vault PDM will just ignore the reference, like it was never there
  if the parent file is ref a local file but that name also exists in vault PDM will resolve the ref to the filename that's already in the vault at check in (I think)

All reference files need to be in the vault or about to be added with the assembly. This setting on the group should prevent checking in an assembly or drawing with references outside the vault.

image.png

When importing a large assembly (x_t and 3D interconnect off) there are a LOT of files saved in a short time, if we have found that if this is done in a vault location while "On Line" PDM will sometimes miss a bunch of these files and they remain as <Local File>. That is one potential reason why there may be duplicate filenames, since these are dropped in the same location as the imported file they may be in a not ideal place. Then I found out that even though PDM is set to delete local files, (which only applies to read only files) does not delete these files because they are not read only as they were never added to the vault so PDM didn't set the read only file flag. So the user unwittingly has duplicate file names that are not in the vault but the path looks like they're in the vault. There are no refs to them in PDM because they are not in the vault, other uses do not see them because they are local only and the person on that computer doesn't realize what's going on.

Not for the same reason, but we train users to import files on their hard drive outside PDM so as not to create all of those files. The reason we do that as we may not add all of those files to the vault. Often an external vendor assembly we make all components "Virtual" since they don't have our part numbers, just the assembly. They import and cleanup then move to the vault. It's faster and cleaner on the database as even files they don't check in are still recorded in the DB as a version 1, even if they delete them.

Next, when another user opens the parent assembly SW will do it's best to find that file, if it can (unfortunate) and the user fails to notice the dialog that disappears in 10 seconds that SW is using some other file now they are unaware of what's going on and think I'm going to yell at them for not getting files as referenced.[/list]

Only thing I can suggest is to create an environment and training that minimizes the chance to have any duplicate files. If there isn't another copy floating around, then it can't "find" the wrong file. Easier said then done, right? When this comes up, I instruct the user and what they did wrong and how to fix it, usually that painful lesson sticks since they won't want to repeat the experience.....usually. Again, I don't know your landscape so there may be good reasons for the copies.