lost reference paths when upgraded from windows 7 to windows 10

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

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

I.T. is handling the problem. I am working on a WSDOT Project and there have been some config changes and  new shortcuts created for my system. After years of not using MS i am just getting back into it I wish I new more. Thanks for all the help and suggestions.

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

Robert a lot of what you are saying is incorrect. 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. 

Your issues are not the same as what this user is encountering. Your workflows involve changing the actual files being referenced. IE: I want to use file located on drive P: today and then tomorrow I want to use the file located on F:/vendor_743/. In this case neither the full path or the relative path will work.

I believe what this user was encountering was that the IT department did not remap the drives on the new machine/OS and MicroStation was not able to resolve the references because these drives were not there (or mapped differently). The reference files did not move. The paths to the references were just not available.

Hi Tim,

Tim Hickman said:

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

Tim Hickman said:

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: