Connect / networked location of Datasets

Question

Still in the process of setting up Aecosim Connect I've run into a problem when trying to setup our networked company workspace. 
 So far I was able to configure my PC that it reads configuration files from the network. 
 The problem I have now is that I am unable to define the correct location of the datasets. 
 
 TF_DATASETS points to the local drive. By doing a little research I found out that this variable is defined in the program folder that way: TF_DATASETS : $(_TF_WORKSPACEROOT)Datasets/ 
 _TF_WORKSPACEROOT also points to a local folder The local definition of this variable is: _TF_WORKSPACEROOT : ${_USTN_CONFIGURATION} 
 _USTN_CONFIGURATION points to our network drive. 
 
 So in theory _TF_WORKSPACEROOT should point to our network drive, which is doesn't 
 On assuming that something isn't working, I have defined _TF_WORKSPACEROOT in the WorkSpaceSetup.cfg file in that way. 
 %lock _TF_WORKSPACEROOT = M:/Microstation/Workspace_Connect/Configuration/ 
 The funny thing now is, that this doesn't change anything - the variable still points to a local drive. 
 Any ideas?

Marc Thomas · Answer

Hi Andreas, 
 Create a network configuration as described in the wikis/blogs linked in your other thread (preferably for initial testing create it locally as mentioned in my post to that thread) [Replace the ... in the paths below with your own path.] 
 Copy the dataset to the network , e.g.: ...\CONFIGURATIONS\CE\Datasets 
 In the network WorkSpaces folder: e.g.: ...\CONFIGURATIONS\CE\WorkSpaces create a folder called NM_Projects (just for testing) 
 In this folder create new file NM_Projects.cfg, paste the following lines into that file: 
 _USTN_WORKSETROOT = .../ProjectData/$(_USTN_WORKSPACENAME)/$(_USTN_WORKSETNAME)/ _USTN_WORKSETDGNWS = $(_USTN_WORKSETROOT)Standards/$(_USTN_WORKSETNAME).DGNWS TF_DATASETS = //hal/CONFIGURATIONS/CE/Datasets/ 
 (The TF_DATASETS definition here will point to the network) 
 In ...\CONFIGURATIONS\CE\WorkSpaces\NM_Projects 
 a) create a folder called WorkSets 
 b) copy the folder and content from C:\ProgramData\Bentley\AECOsim CONNECT Edition\Configuration\WorkSpaces\AECOsimExamples\Standards 
 c) Copy file "C:\ProgramData\Bentley\AECOsim CONNECT Edition\Configuration\WorkSpaces\AECOsimExamples\worksets\BuildingTemplate_NM.cfg" into ...\CONFIGURATIONS\CE\WorkSpaces\NM_Projects\WorkSets and rename to NM_Project_001.cfg. (this file does not need to be edited, it will find Dataset_NM) 
 In ...\ProjectData create a folder called NM_Projects 
 Copy the example template folder and contents (obviously): C:\ProgramData\Bentley\AECOsim CONNECT Edition\Configuration\WorkSpaces\AECOsimExamples\worksets\BuildingTemplate_NM into ...\ProjectData\NM_Projects\ and rename to NM_Project_001. 
 You should end up with this:

The only change needed on the c:\ drive is to SetupConfiguration.cfg as previously discussed. 
 Note that the DGNWS file is created in the ...\ProjectData\NM_Projects\NM_Project_001\Standards folder where it can be written to by users. 
 ...\ProjectData can be on different drive/share, they are only in the same place for simplicity here. 
 Hope this helps to clarify things?

Marc Thomas · Answer

Re-reading and stepping back from the detail in my previous post, I still recommend changing the default datasets location using TF_DATASETS. Try adding: 
 TF_DATASETS = <path to my networked dataset> 
 in ...\Organization\Standards.cfg, e.g.: 
 TF_DATASETS = M:/Microstation/Workspace_Connect/Configuration/ 
 That defines the location of the networked datasets. 
 The TF_DATASETNAME statement in the WorkSet.cfg (equivalent of V8i PCF) will define the name of the dataset to be used by the WorkSet. e.g.: 
 TF_DATASETNAME = Dataset_NM 
 The example BuildingTemplate_NM.cfg contains this statement. 
 
 The correct syntax for the locked example statement above should be: 
 _TF_WORKSPACEROOT = M:/Microstation/Workspace_Connect/Configuration/ %lock _TF_WORKSPACEROOT 
 You have to set the variable then lock it. However a lock is normally only really needed if you wish to prevent users from changing standard settings in the UI. 
 Locked variables are best avoided as they can have unexpected results downstream.