OpenRoads Designer (2019 R1) SUDA Libraries (.xml files' home location)

Hi Shannon,

I'm trying to find out whether you can define this location at install time or not. 

Whilst we do write files to it when you install OpenRoads Designer, you should be able to browse to library files in any location.

Can I ask why your users can't access this path? A lot of Bentley products write files to the C:\ProgramData\Bentley\ path. 

Regards,

Jon

Jonathan asked me to assist you with your question. I can answer this based on how SewerGEMS works, and since SewerGEMS is the technology integrated into OpenRoads Designer for hydraulic modeling (including engineering libraries), my answer *should* be accurate, but there may be some slight differences in the SUDA/ORD implementation where Jonathan can help.

The location of the default engineering libraries is not controlled by a variable, but rather by way of the paths encoded in a special database.

The default engineering libraries that appear in the Engineering Library manager are based on XML file paths established in the EngineeringLibraries.sqlite file. This database acts as a registry of the locations of all the individual XML files available in the Engineering Libraries manager. When you add a new library XML file, it gets added to this database so that when you open the product the next time, it is still listed. For SewerGEMS, the EngineeringLibraries.sqlite file is located here: %userprofile%\AppData\Roaming\Bentley\EngineeringLibraries\

The default EngineeringLibraries.sqlite contains paths to the default Engineering Library XML files. To change them, please try the following:

1) Move the default engineering library XML files in question from the original path (the one you say that users cannot access), to the desired location
2) Open the product, start/open a project, open the Engineering Library manager and delete out any left-over entries
3) Click the New button > Add Existing Library, then browse to the new location of the XML files. This adds the locations to the EngineeringLibraries.sqlite on that computer, so it knows where to look each time the product is opened.

If the new location is a network share accessible by all users, then you may be able to apply this change to all users by copying the EngineeringLibraries.sqlite. Note that this is not something that I have tried before and if there are user-specific unique IDs stored inside that database, it may not work on other computers. Alternatively on the other computers, you could remove the old default engineering libraries if they are still present in the Engineering Libraries manager, "add existing", and browse to the new location where you placed the XML files.

Note that in some cases you may want to set up your own standards in a separate XML file. For example your county storms, standard pipe sizes, inlets, etc. (as opposed to using the default libraries).

Sorry, let me clarify - the users are able to view this location but are not able to write (IT security) to anywhere except the Users\Public\ location, so as we create our own .xml's they cannot be stored anywhere except in our environment which is set-up in the Users\Public\ (redirected via .cfg) locale.  I'm putting a follow-up response to Jesse below which may help explain a little more of what more is happening.

Slightly off-topic, but clearly related to portions of your clarification post.

As I understand it, the C:\ProgramData\ folder structure is intended to be a "shared by all users" data storage area that programs can read and write to for items that are editable by users, but need to be shared by any user on that PC. If your IT Security locks this location down, they may find there are a number of other programs that this policy screws up.

I may be wrong about this, but the workspaces get installed in this location by default and we have found that occasionally a user should be allowed to make edits to some setting that is saved in a file found in that folder structure.

Hi Jesse.

I suspected that by removing them from the 'list' and only populating .xml's that we have in our environment under Users\Public\ that would 'hold' the settings, however, even after clearing the list and repopulating it with just our files, even Saving Preferences and the like, anything in the ProgramData SUDA Libraries folder will repopulate the list every time.  The only way I've been able to stop that is by renaming or removing the Libraries folder.

Part of the issue may arise because our users have no 'writability' to these locations as well (IT Network Security - our users only get to write to the Public location), so our environment, via the .cfg files, are wholly redirected to the Users\Public\ location and they need to use only our standards so we want our data 'front-and-center'.

We're trying to leave the 'default install' alone so we don't have to address relocations/renames after software updates and such and to essentially only provide our environments' data to our Users.