Just got upgraded to windows 10 from windows 7. when i open a drawing all my reference file paths are broken. Once I re-path they are fine when i re-open. i have a lot of drawings, Is there a fix for this or do i have to re-path all the drawings?
I am curious on how the references were being resolved prior to the upgrade ?
This has been on of my frustrations for the last ten years. Microstation does not have a reference-file-specific option to "save full path." In order to reference a file on a different hard drive letter, you have to set a configuration variable to save a "hidden" full path for every reference file that you ever attach, whether you want to save a full path or not.
In this case, I would guess that they meant to have a relative path saved, or even a full path saved, but that was not executed properly. Even so, due to the automatically saved "hidden" full path, Microstation was able to load the reference file from the location that it was previously found. Being that the referenced file showed up properly, no one realized that there was a problem. Now, (potentially years later), there is a slight change in the full path. That creates two problems: 1) The reference file is not found and 2) the saved full path is HIDDEN (can not be seen by the user), so the user does not have any clue where the file was previously found.
Microstation needs the ability to either 1) have an option to save a full path or a relative path, or 2) When no relative path is available, save the full path. This would allow to disable the hidden full path feature and continue to work without the problems that configuration variable creates.
All I can say it that a check list is used for the references to be resolved.
Is it in the same folder as the active file ? no - move to the next...Is a configuration used ? no - move the next, etc... on down the line.
The fact that it is picking the wrong file or not finding one at all, is based off of your design/setup.
Which is why I asked the question:
Tim Hickman said:and the full path (it's original location) is checked last.
That is one of my issues too. In my project folder, I have a "Floor Plan" file that is reference into my drawing. I am now given the task to compare that "Floor Plan" to a "Floor Plan" file on my desktop or on the "archived project" drive. If I reference both the "Floor Plan" from the current folder and the "Floor Plan" from the other drive, and then re-open my drawing, I will see two copies of the file from the current folder--ignoring the full path that I intended. If I don't realize that this happened, I can spend an hour comparing the files to conclude that there are no changes. I take that info back to my boss, and in two seconds he says, "That makes no sense--the room on this floor plan is obviously different than the room on that floor plan."
I'm sorry that this is slightly off topic from Terence's issue, but the cause is related. When storing a full path can only be done globally, rather than on specific referenced files, you get problems because you do not want a full path stored (but it is stored anyway) and when you do want a full path store (because the full path is the last place looked.)
My question is "How were the references INTENDED to be resolved prior to the upgrade?" If the user had the correct tools, then we could tell what what happened and how to fix it. As far as I know, these may have been intended as relative references, but no issues were obvious because of your "check list" including a "last known full path".
lets' say it was INTENDED to be resolved by MS_RFDIR.
Now the IT department gives the user a new machine with new software and this was not set. So due to the IT departments mistake - how would you like the software (which has no idea of the INTENT) to resolve this ? Initially the software was configured to do this. Now this has changed and now based off of that change, it is unable to resolve the reference issue.
This is not limited to just references. If the IT department changes a server name or a mapped drive and tells no one, and you have a workspace out there, then MicroStation would suddenly not be able to find your workspace. So how the workspace was intented to be resolved fails.
Tim Hickman said:lets' say it was INTENDED to be resolved by MS_RFDIR
If the intention is to resolve this by MS_RFDIR, then the problem lies with the setup of Microstation and it's configuration variables. This is true of using specific configuration variables in a reference as well--ie for "Details2019:Detail-01.dgn" to resolve, the "Details2019" configuration variable needs to be set up properly.
I do not expect Microstation to know the user's intent. What I do want, is a way of specifying your intent, especially related to the storing of full path information. If the user specifies a "relative path" or "configuration variable", Microstation should not save a "full path" in the background and not give the user a warning about using that "last resort full path". Also, the user should be able to specify a full path, and be able to see and confirm that full path, and not have Microstation find a different file in the "check list" before it gets to that full path.
Tim, you are totally correct. If Microstation is not set up correctly, then your drawings will not show correctly. There are configuration variables, preferences, etc. which will affect the way your drawing appears and prints.
Tim, I am also going to venture to say that I am also correct. Either of us could be correct in the initial problem, but there is a secondary problem going on here:
Terence Johnson said:Once I re-path they are fine when i re-open.
Now if the intention was to use the full path, Terence is doing the correct fix (maybe). If the intention was to use any other method, including MS_RFDIR, he is wasting his time fixing the hidden full path. He putting a temporary fix on the result, and not addressing the problem. If anything, this could hide the real problem until it becomes an even bigger one.
So either and/or both of us could be correct for this user's situation. Unless we get more information from their IT department, we will never know, and it really doesn't matter (as long as they get it fixed). My hope is that the typical user is given the choice of (storing a full path) or (not storing a full path), so when this is an operator error (rather than a setup error), we won't get surprised when the full path is changed. (And just as a side note, my comments are not just theoretical. I have personally encountered these issues. Also, a couple weeks ago my coworker, who works from two different locations, had her reference files "break" because she did not realize that Microstation was depending on the hidden full path. Her orders were to get the project sent out immediately, but she was unable to do that.)