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

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).

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.

If the list of attached XML files in the Engineering Libraries manager is not "sticking" and reverting after you re-open, that may indicate that the paths to the XML file locations did not save to the engineeringlibraries.sqlite file (as mentioned this is the engineering library registry). 

For SewerGEMS, the engineeringlibraries.sqlite file is stored %userprofile%\AppData\Roaming\Bentley\EngineeringLibraries\ and I would think that users should have access to their own user profile. Perhaps initially you can sign in or run-as-admin on the program shortcut, fix up the Engineering Libraries manager (writing the new locations to the engineeringlibraries.sqlite file), and then have the user sign in? 

If the location of the engineeringlibraries.sqlite file is different for OpenRoads Designer, Jonathan can help clarify the exact path.

I saw that filename in your first response and wondered if that was what I would need to look at and then if it becomes a 'user specific' file, which I may be able to get set-up (customized) and placed with 'install' for the users.  At least I have another option to take a look at.  And I have confirmed that I am seeing the following location / filename:

Users\<USERNAME>\AppData\Local\Bentley\EngineeringLibraries\EngineeringLibraries.sqlite

Thank you for your responses.

Yes, this file updated when I changed out some of the library list, however, everything in the ProgramData Libraries folder will still repopulate itself into this file / list even after I've removed them from the listing.  It appears that right now, the only way I can stop them being seen in the Engineering Libraries list is to remove them from the Libraries folder altogether or renaming that folder, however our added Libraries appear to be holding on.

Now it would become getting the users setup.  I'll give that some looking into next week.

Thanks again for the responses.

I'm thinking that read access to the libraries that ORD ships with could be a good thing, because we may well include libraries that you need to use. Not being able to access them at all doesn't sound like a good idea - in my opinion. If your IT policy prevents you writing to that location, and your users need to pick another location to write their own libraries, then that sounds okay to me, because the software lets you choose the location when you export to a library.

I'm thinking that read access to the libraries that ORD ships with could be a good thing, because we may well include libraries that you need to use. Not being able to access them at all doesn't sound like a good idea - in my opinion. If your IT policy prevents you writing to that location, and your users need to pick another location to write their own libraries, then that sounds okay to me, because the software lets you choose the location when you export to a library.