Wiki » History » Version 1

Version 1/2 - Next ยป - Current version
Beau Harrison, 07/13/2020 12:35 PM
Create database deployment process.

ESH Directories

Four databases contain the data needed to run and configure the Safety System applications on the Safety System servers. The system will not work without the databases. The FileMaker Pro databases are used to maintain the data and export the data in a tab-delimited file.

The esh directories area, /esh/directories/, of the Safety System servers contains tab-delimited files for related systems.

Database access

The sole source of truth for the databases is in FileMaker Pro that can be accessed from a Windows computer with FMP installed. The FMP database files are located at \\\\Interlock Group\Projects\SScomputer\DATABASES FMPro\.

Note: Databases are single-user access only.

Database modifications and updates

Note: Changes to the database are immediate and irreversible.

Database export

The FMP DB can be exported in the desired server format, tab-delimited, to the desktop via an export script in the script menu. The exported files have an "esh_" prefix.


Testing is automated using GitHub's Actions. When files are updated on the development branch and pushed to the origin, the tests are automatically run, and a pull-request to the main branch is created if the tests pass.


When an approved pull-request is merged into the main branch, the automated deployment workflow will be triggered to deliver the database files to the Safety System Servers at /esh/directories.

Some application changes will be visible when a new application is opened but changes to the data pool will require the data pool to be destroyed, rebuilt, and applications to be restarted. This is done with the /esh/eshRESART script.

Note: Interlocks and the MCR should be contacted before running the restart script as it will close their applications.


When using a previously used AART data pool offset, remember to send the updated AART config to the applicable LEPR as well as the LEPR that used that data pool offset previously. Failure to do this will result in a working data acquisition card in the system and an AART that is intermittently "MALF'ed" by the previous LEPR due to no response from the missing data acquisition card. The AART diagnostics screen will show a status that appears to indicate a hardware issue associated
with a problem in the field.

This can be avoided by updating the LEPR that an AART is assigned to when removing an AART.