[MS CE U16.2] Nested reference files reading local directory & not displaying

Today things are back to 'normal'. When I reference a file from a folder external to the one I'm working in, all the attached and nested references from that external folder come in and show up as I've come to know & love. Nothing is replaced by the local version because of like-naming issues.

It probably needed me to walk away for the night in order to get things to work the way we're used to.

A lot of good insights were explored and suggestions made. Thank you all for the help.

If anyone wants to pick this apart further and/or have questions, post them up and I'll do my best to reply.

Here's what I get today. Reference is on the right. They share file names, but in different folders (COMP, TOPO).

This is what I got yesterday:

Half the information was missing because the COMP and TOPO files were pointing to the directory I was working in.

All I can say in excuse was it 'fixed' itself. My apologies for the wild goose chase everyone, but again a lot of good analysis and insights were deposited here.

Stephen, those configuration variables aren't set correctly.

e.g.

Stephen Kareiva said:

MS_RFDIR
$(_USTN_WORKSETSTANDARDS)Sheet Borders\
$(_USTN_WORKSPACESTANDARDS)Sheet Borders\

Should be:

MS_RFDIR = $(_USTN_WORKSETSTANDARDS)Sheet Borders\
MS_RFDIR > $(_USTN_WORKSPACESTANDARDS)Sheet Borders\

The first line with the '=' sets that expanded path as the first assignment to MS_RFDIR
The second line with the '>' adds the next expanded path to MS_RFDIR by appending the existing assignment.
This allows multiple folders to be set and for MicroStation to search for your reference attachments.

Barry Lothian said:

You guys on CONNECT no longer have projects,

Actually, the way we have our CONNECT workspaces setup we have Projects. Our Workspace drop down loads the Client standards and the Worksets drop down loads the Project.

Barry Lothian said:

Stephen, those configuration variables aren't set correctly.

If a variable is not defined correctly then it is ignored, that is if it does not cause the program to get confused and lock up or force shutdown.

I am using no workspace/no workset in Connect for testing.

I have been busy and haven't had time to follow up on any of this....

still testing when I have a chance.

ok - did some testing.

What I found was that if a reference is attached with no relative pathing, then it follows the results I have posted previously. If a reference is attached using the relative pathing, then Barry L's results are what occurs.

The MS_RFDIR variable has no effect on either workflow - I tried this with it defined as well as undefined.

My conclusion from all this, is that if the OP was seeing issues with a file when it existed in the same folder as the active file, then the references were attached without a relative pathing.  

HTH

ok - did some testing.

What I found was that if a reference is attached with no relative pathing, then it follows the results I have posted previously. If a reference is attached using the relative pathing, then Barry L's results are what occurs.

The MS_RFDIR variable has no effect on either workflow - I tried this with it defined as well as undefined.

My conclusion from all this, is that if the OP was seeing issues with a file when it existed in the same folder as the active file, then the references were attached without a relative pathing.  

HTH

Tim, I follow your logic and I believe you're right. That's how MicroStation SHOULD work. Relative ON = nested refs ride along with the file being referenced. Relative OFF = would pull like-named files from local work directory. Our issue was Relative ON = pulls from local work directory which ≠ correct operation of the program.

Between yours and Barry's analysis, it looks like the configs around here desperately need cleaning up. But they had no bearing on the issue that we've run in to.

In the end it wound up being an overnight 'it fixed itself'. It may have been server or network problems as that has been a thing recently.

I was just reviewing reference-related config variables in the help file, and I just noticed this:

MS_ALWAYSRELATIVEREFPATH: If set (to any value), always turns on the Save Relative Path check box and disables it so that it cannot be turned off. It will save relative paths whenever possible.

To any value? What an illogical decision that was to make it work like that. I can't think of any other Configuration Variable which uses that same mechanism and phrasing, its usually always "If set to 1..." = Active "If set to 0" = Inactive.

As I wrote in a previous post, one of my CFG files has MS_ALWAYSRELATIVEREFPATH = 0, whenever I originally wrote the file many years ago, I'm certain I would have been thinking it was to make the variable inactive, else I would have written 1 not 0. Not that I have a preference of full paths or relative paths, I just find it a dumb decision that the variable isn't operating in a conventional boolean mode, and that you can write almost anything to activate relative paths.

Stephen Kareiva said:

Between yours and Barry's analysis

Barry Bentley didn't just analyse the reference attachment algorithm: he designed it.  He's one of the originators of MicroStation.

Barry Lothian's analysis, Jon.