Working through changes to the build and I'm getting an exception error when loading the build which I think is related to the old catalogs. Only issue is that i can't get the correct paths to load.
in the config dialog, both:
DG_PATH
and
DG_CATALOGS_PATH
show correctly:
When I open the Catalog Editor you have it point to another local directory. Has anyone else come across this before?
I have them locked now as it appeared they were being changed down the line (not sure where at the moment). Anyone else come across this?
All help appreciated.
Hi Sean,
DG_CATALOGS_PATH is a child variable driven by preceding variables such as TFDIR, it should not be locked.
Out of the box TFDIR points to the installed datasets and includes folders at Organization, WorkSpace ad WorkSet levels.
TFDIR is defined by $(TF_DATASETS)$(TF_DATASETNAME)\
I'm assuming that a) you want the default dataset to be in the N:\ path shown above, where you copy Dataset AU to the network and customise it to your needs, and b) your dataset update strategy is to pull in updates from future dataset versions as they become available (e.g. additional or new content required for new/updated features)?
Once you have defined the path to your network configuration using ConfigurationSetup.cfg, the standards CFGs in that location can modify TF_DATASETS to the appropriate path in your custom dataset.
TF_DATASETNAME sits in the WorkSet.cfg, e.g. at line 14 TF_DATASETNAME = Dataset_AU.
Hope this helps to set you in the right direction?
Marc
'Hope this helps to set you in the right direction?'
Not really, the problem I now have is because it seems we're forced down a config path is breaks what I need to happen. I'm not interested in returning to a situation where ucf files create chaos.
I need to work with this more.
Hi Bob,
The three filter variables should not point to the same place, they are specifically designed to point to the three separate configuration levels.
Leaving BB_DATASET_WORKSPACE_FILTER and BB_DATASET_WORKSET_FILTER at their default values should work correctly.
BB_DATASET_ORGANIZATION_FILTER = $(BHP_DATASET) should point the Catalog Editor UI at your copy of the dataset instead of the C:\ drive version.
If you can share your configuration files with us via the SR you filed or use Bentley Configuration Explorer to export a .BCF file we will have a better understanding of your configuration.
Please can you show us how you have redirected your configuration to the network, it is quite possible that a variable earlier in the process needs to be set to tidy this all up.
Hi Marc,
I just set every Datagroup configvar I could find to point to the server as a test, so that in theory there should be nothing going to C:\.
It didn't work as I still had files going to C:\.
I will upload my config files for you via the service ticket.
Thank you, we will take a look at your CFGs and get back to you shortly. There is a configuration option that may resolve this, but we need to review it in the context of your CFGs before posting here.
We're replying to Bob's specific situation via his SR.
The generalized solution for directing the Dataset root for OBD to a Custom Configuration is as follows:
On the C:\ drive set the location of a Custom Configuration in the ConfigurationSetup.cfg file, [General] section
_USTN_CUSTOM_CONFIGURATION = W:/OBD/Configuration/
This will result in _USTN_CONFIGURATION being resolved to W:/OBD/Configuration/
In the root of the Custom Configuration, in this example: W:/OBD/Configuration/, modify WorkSpaceSetup.cfg (this can either be a copy of our delivered file, or simply a new file with that name containing only the required statements. Note do not include a copy of ConfigurationSetup.cfg in this location, it should only exist on the c: drive). Note, this file must be called WorkSpaceSetup.cfg.
Unless other statements are appropriate in this file, all that is needed are these two lines:
%undef _TF_WORKSPACEROOT_TF_WORKSPACEROOT = $(_USTN_CONFIGURATION)
The first line clears the existing definition of _TF_WORKSPACEROOT, the second applies the required definition.
At the moment I don't have a clear understanding of why the %undef is necessary, but this has been tested and works. Without the %undef statement the application will always use the delivered datasets.
Update 7
For future reference, when Update 7 is released (soon) this behaviour will reverse!
Simply defining a Custom Configuration location will make OBD look for the Dataset root in the Custom Configuration (and to be clear, this only applies when a Custom Configuration is defined). In that use case both _TF_WORKSPACEROOT statements can be omitted from WorkSpaceSetup.cfg.
To use the delivered Datasets the statements in WorkSpaceSetup.cfg at the root of the Custom Configuration will need to be:
# Update 7 and later to use delivered datasets%undef _TF_WORKSPACEROOT_TF_WORKSPACEROOT = $(_USTN_INSTALLED_CONFIGURATION)
Marc Thomas said:%undef _TF_WORKSPACEROOT_TF_WORKSPACEROOT = $(_USTN_CONFIGURATION)
Marc Thomas said:At the moment I don't have a clear understanding of why the %undef is necessary, but this has been tested and works. Without the %undef statement the application will always use the delivered datasets.
Thanks Marc. Another clipping for my unofficial CE Admin manual.
How did you go with this guys? Stuck at a similar spot and can't get the network locations to appear despite the C drive location not appearing in the config dialog.
I think Bob's issue was sorted out. -WS was used to launch OBD and that's broken in OBD. Not sure if that been fixed in the latest update.
Hi Bear,
Sorry for the late reply.
I've been on holiday for the last two weeks.
Tuan is correct, the -ws prefix was causing all my problems.
He solved it by suggesting I use the SET command prior to starting OBD.
I run my builds from a batch file using the following code:
@echo offset _USTN_CUSTOM_CONFIGURATION=M:\CAD_Build_OBD_BHP\Configuration\START "" "C:\Program Files\Bentley\OpenBuildings CONNECT Edition\OpenBuildingsDesigner\OpenBuildingsDesigner.exe"
Bummer, looks like I'm going to need to try another work around. I use a cfg file in the appl directory, this is why I hate these sorts of changes.
These fixed name cfg files are unnecessary, JMO.
So, I've changed the name of the cfg file I use in the appl directory to ConfigurationSetup.cfg.
I have then changed my other build cfg to WorkSpaceSetup.cfg
All of the variables are still being set, but the path displayed in the catalog editor still refers back to the default location even though the path doesn't appear anywhere in the config dialog.