lost reference paths when upgraded from windows 7 to windows 10

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?

Parents
  • I am curious on how the references were being resolved prior to the upgrade ?

    Timothy Hickman

    CADD Manager | CADD Department

    timothy.hickman@colliersengineering.com

    Main: 877 627 3772| 

    1000 Waterview Drive Suite 201 | Hamilton, New Jersey 08691

  • Hi Tim,

    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.

    --Thanks,
    --Robert

  • Hi Tim,

    When a reference is attached, the full path is stored. The product has a check list it works thru to solve the references, and the full path (it's original location) is checked last.

    Hi Tim,

    Per Microstation CE configuration notes for MS_DISALLOWFULLREFPATH, "When set to 1, MicroStation does not save the full path to references. By default, MicroStation stores both an abbreviated (portable) path and the full path to references. The full path will be wrong if the directory structure for a WorkSet is changed or if a different file server drive letter is used, so it can cause inconsistent reference file location in those situations. Therefore, some sites prefer that the full path not be saved."

    With this variable set to 0, you a full path is automatically saved in the background, where the user can not see it.  That is why I call it "hidden".  If you intend to use a configuration variable or a relative path, and you miss that setting, the reference file shows up perfectly the next time you open Microstation.  There is no warning that your file is messed up.  Then if any change is made to the full path, your reference breaks and there is no clue on where the reference file originally was.  That full path is hidden from the user.

    With this variable set to 1, there is no way to reference a file on a different drive letter and be able to re-open that drawing to see the reference file.  As currently set up, there is no front-end place that will store a full path.  That means that if you want to attach files from a separate drive letter, you have to set MS_DisAllowFullRefPath to 0, or use a configuration variable (with it's complications).

    MicroStation was not able to resolve the references because these drives were not there (or mapped differently)

    Tim, that is exactly my point.  If you look at Terence's screen shot, you will see a list of reference files with no configuration variable and no relative path.  Why don't you see a relative path, a configuration variable, or a full path?  There could be a number of reasons, but they all fall under my previous comments.
    --Reason #1:  It is on a drive that is no longer there. -- The user wanted to save a full path, but the saved full path is hidden, so we can not tell what the original drive letter was figure out why it is missing.
    --Reason #2: The drive is mapped differently. -- This error could be caused by several different things.
        a) The user intended to save a full path.  The issue is that you don't know what that full path was, so you may have to do a lot of work to figure it out.  (IE the full path was "P:\Vender 123\Project abc\Case 25" and P: was change to F:.  If we knew the original path, it would be an "easy" fix to apply to many files.  If we are not sure about the path, how do we find the correct file?)
       b) The user intended to save a relative path, but did not notice (or did know of) the "Save Relative Path" check box was unchecked.  The user attached the intended-relative-path-reference-files, reopened the drawing, and everything showed up fine.  Then when the drive was remapped, all the references broke, even though the references are all on the same drive.
       c) The user could have intended to use a configuration variable, and perhaps reattached the files from the same folder defined by that configuration variable.  When you re-attach from that same folder, you lose the configuration variable, but due to the hidden full path, the reference file shows up correctly.

    The bottom line is that we don't know what the IT department has to do.  If the references are on the same drive as the main files, there should be a way to not save the full path, so you are not hit by these big surprises in the future.  At the same time, there should be a way to save a full path for a reference file that "does not have a relative path".  (Personally, I say that if a file is on a different drive letter, the "relative path" is the same thing as the "full path.")  Even if a full path was intended, that full path should be visible to the user, so they can figure out where the file was (and where it now is) to fix the problem when the path breaks.

    --Thanks,
    --Robert Arnold

  • 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: 

     

    I am curious on how the references were being resolved prior to the upgrade ?

    Timothy Hickman

    CADD Manager | CADD Department

    timothy.hickman@colliersengineering.com

    Main: 877 627 3772| 

    1000 Waterview Drive Suite 201 | Hamilton, New Jersey 08691

  • and the full path (it's original location) is checked last. 

    Hi Tim,

    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.) 

    --Thanks,
    --Robert

  • 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".

    --Robert

  • 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.

    Timothy Hickman

    CADD Manager | CADD Department

    timothy.hickman@colliersengineering.com

    Main: 877 627 3772| 

    1000 Waterview Drive Suite 201 | Hamilton, New Jersey 08691

Reply
  • 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.

    Timothy Hickman

    CADD Manager | CADD Department

    timothy.hickman@colliersengineering.com

    Main: 877 627 3772| 

    1000 Waterview Drive Suite 201 | Hamilton, New Jersey 08691

Children
  • Hi Tim,

    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: 

    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.)

    --Thanks,
    --Robert