Modifying Helix ALM databases

You may store Helix ALM data in an RDBMS database instead of the Helix ALM native database format. It is possible to modify the internal database format and data from the RDBMS, but we strongly discourage it. Your maintenance contract does not include support for recovering from these types of database changes.

Configuration changes

For both native and RDBMS databases, you can configure field names, custom fields, workflows, notification rules, and more. We recommend making these changes using the Helix ALM Client rather than at the database level. Making changes directly in the database requires a full understanding of the database format and the rules enforced at the software level. Making changes directly in the database skips processing of audit trail logging, email notifications, calculated custom fields, etc.

Database table changes

Do not reconfigure the database format. When you rename a field in the client application, the database column names do not reflect this change. Do not change database tables/column names, modify column size/attributes, or make any other structural database changes because it will result in errors using Helix ALM.

Live updates

Helix ALM caches data to improve the performance of complex reports and filters. Do not perform live updates of Helix ALM at the database level unless the Helix ALM Server has been shut down. Adding, editing, or deleting data while the server is running results in errors and potential data loss. Your changes may be overwritten next time the item is modified because database changes are not immediately read into the memory cache.

The native database format prevents users from opening the database in read/write mode while the Helix ALM Server is running. However, Helix ALM does not implement similar locks when running against an RDBMS database. To perform live data updates, use the SOAP SDK, REST API, bulk field changes, or other methods available in Helix ALM clients.