We've got a file that needs to be opened in the correct client build (Build A).
We start CAD (Connect edition MS 16, OB 10), select Build A, browse to the file, and open it.
When CAD finishes opening it is in a different build (Build B).
There are no warnings, there are no options to stop it. We literally can not progress the drawing if we can not open it in the correct build. If there isn't an effective control for this then the products should be considered defective.
How can we open the file in the selected build?
How do we stop CAD from switching to Build B when it opens the file?
We've tried file the 'file disassociateworkset' and save settings work around, but it doesn't work, it still switches to Build B. We've tried deleting the preferences, but that doesn't work either.
Hi Michael,
Just as a diagnostic test, if you open the file in MicroStation with No WorkSpace; No WorkSet, does the a WorkSet association dialog appear?
Have any of these related variables been set in your configuration?
MS_WORKSETMISMATCH_ALERT_EXCLUDE_VARS_ALLLEVELSMS_WORKSETMISMATCH_ALERT_EXCLUDE_VARS_WORKSPACELEVELMS_SUPPRESS_FILE_WORKSET_ASSOCIATION
Marc
Hi Marc
No workspace opened from my local C: drive gives the message 'Can't find Build A, do you want to continue with no workspace'
No workspace opened from the network location doesn't give that message.
MS_WORKSETMISMATCH_ALERT_EXCLUDE_VARS_ALLLEVELS is undefined
MS_WORKSETMISMATCH_ALERT_EXCLUDE_VARS_WORKSPACELEVEL is set to MS_DEF, MS_CELL, MS_SEEDFILES etc
MS_SUPPRESS_FILE_WORKSET_ASSOCIATION = 1
OK, I think it may be the last one. That issue has been discussed here before.
MS_SUPPRESS_FILE_WORKSET_ASSOCIATION = 1 hides any messages and accepts the default option. That default may not be the option that you want, but we don't have any control over that via variable at present. There is an existing enhancement request, 662328 Configuration variable with multiple options for WorkSpace/WorkSet mismatch alert, for the ability to offer:
"three options for how the Workspace/Workset mismatch alert is handled:
If you would like to support tis please file a Service Request mentioning enhancement 662328.
To confirm that this is the source please try working with MS_SUPPRESS_FILE_WORKSET_ASSOCIATION undefined.
Although your test using the disassociate key-in does make me wonder if something else is involved.
Thanks Marc, I undefined MS_SUPPRESS_FILE_WORKSET_ASSOCIATION and the user now gets a choice. However I can't %lock it as undefined. Also having it undefined prevents us from running scripts effectively.
I think the workspace / workset arrangement would be good when you have one CAD build with multiple projects. However, most users in the mining consultancy industry have multiple clients, each with their own CAD environment. Working around the workspace / workset arrangement becomes even harder when we are using projectwise, because the file just doesn't open, and the error message isn't specific enough for the user to understand what is happening.
What's your best guess for when enhancement request 662328 will be actioned (if at all)? otherwise I will have look into splitting all our client builds into different network locations, and develop some kind of man-in-the-middle method of directing CAD to that location. We have client builds for Microstation, OB, ORD, OP, BRCM, and PS which I would need to re-configure, that's the scale of how frustrating this issue is.
I've added a link to this thread to that bug to add to the existing information.
If you could file a service request asking to be linked to the bug, that will help with prioritization, SR count is one of the factors involved.