In CONNECT how do you direct a Workset to another drive away from the parent Workspace

you also have a forward slash at the end of the   _USTN_WORKSETSDGNWSROOT = $(_USTN_WORKSETSROOT)/   line. In the previous variable definition, it is already pointed to a folder, so the forward slash on the DGNWSROOT should not be needed.

Good Afternoon Tim,

The company's Standards are kept at the Organizational level which would be everyone's PC.  So the two Workspace configurations have very little in them except direction on where their child Worksets are located.  Workspace "Local C" has its Workset location under the "Pin" folder on the "Local Drive / C".  Workspace "Network Y" has its Workset location under the "Pin" folder on the "Network Drive / Y". 

Thank you for your time, 

Or maybe something wrong with the WorkSpace Dialog box where you set the location of the various files?

I created a new folder on my network and it was empty. I then started Connect Edition. At the start dialog I selected my local workspace. I then selected create workset. In the dialog that opened, I keyed in my new workset name, gave it a description and then selected the browse button for the root folder and picked the empty folder out on my network. Doing this filled in the rest of the options (design files, standards files and standards subfolders). I selected ok and it created the workset. Now since the DGN folder was empty, I had to create a new DGN file. I did this, and then entered the file.

It works for me - I am not able to reproduce the issue. Either doing it manually or thru the dialog.

So Let me get this Straight:

1. You didn't create a second WorkSpace that directs to the Network Drive?

2. You created a second WorkSet within your Original WorkSpace which directs this empty dgn folder on the Network Drive?

Because if the above is true that is not what my problem is.

I looking to create TWO WorkSpaces

One with WorkSets on the Local Drive 

One with WorkSets on the Network Drive.

I used the same method that you used to place the Workset on the network and it did work for me. It is possible that something is not working correctly with your install of MicroStation but MicroStation is capable of doing what you are trying to accomplish. You can try running a repair of your MicroStation installation. I would also suggest that you try creating the workspace and workset from a different computer. That will determine if something is wrong with the installation of MicroStation on your computer.

You said, “The company's Standards are kept at the Organizational level which would be everyone's PC”. Most companies prefer to keep their Organizational level standards on the network. If you need to make a change to the standards (add a level to a level library or make a change to a text style), if the standards are local, you need to make the change to every computer running MicroStation. If the standards are on the network, you make the change on the network and everyone gets the change. It is much easier to maintain. You can also make the folders read-only if you wish.

I did create a second workspace to look at the network worksets. As a matter of fact I have 4 different workspaces. One of which is pointing to my network for its worksets - which is what the screenshots show. It is loading my workset *,cfg file off of the network location.

I did create a second workspace to look at the network worksets. As a matter of fact I have 4 different workspaces. One of which is pointing to my network for its worksets - which is what the screenshots show. It is loading my workset *,cfg file off of the network location.

Tim found the solution!

He was able to get my organization's configuration to work with it's particular setup that we have been using since MX.  And work around CONNECT's processing time on search path idiosyncrasy.

Tim was able to:

1. Keep my organizations standards at the Organizational level Local.

2. Use the WorkSpace choice as a switch to either work locally or work off a network drive.  (We do this because Survey work is best done Locally or because of lack of internet, while working off a network has better access for other disciplines and locations.)

3. Only one WorkSpace, the "Local C" WorkSpace has its corresponding "Local C.cfg" file while the "Network Y" WorkSpace only has its WorkSpace.cfg file.  (So there are no standards contained at this level for the Network Workspace.)

*We only have two WorkSpaces "Local C" and "Network Y"

4. The local WorkSpace "Local C.cfg" has All configuration variables "active" within its cfg.

5. The network WorkSpace "Network Y.cfg" has All But One configuration variables "Deactivated" within its cfg.

This has fixed the issue of CONNECT "hanging up" at startup and locking up the PC.  Due to this issue of CONNECT's search path process time, it is best if you follow these guidelines. 

1. The WorkSpaces should be on the same drive as the Organization and the WorkSets are contained just below the WorkSpace in the file structure.

2. Also keep the WorkSet folder, the WorkSet.cfg file, and the WorkSet.dgnws file together (as shown here)

If your configuration requires you to separate these into separate locations and separate drives and you notice unworkable "hang times" you can attempt to improve this by "Commenting Out" configuration variables with search paths within the WorkSpace.cfg.  But REMEMBER by doing so you render the contents in corresponding file path invisible to CONNECT and Will Not Be Read.  For my organization this is not an issue because all disciplines use one set of standards and customizations, That is why you don't see a "Network Y" WorkSpace folder partnered with the "Network Y" WorkSpace.cfg file, because they wouldn't be read by CONNECT anyway (because of the way I have the configuration variables commented out in the cfg).

Hope this Helps!

And Thanks Again Tim for your determination and time that you put into this resolution, Peace,