How to use fully-qualified table names in the PegaRULES database
By default, Process Commander uses only the database table name to identify tables for database queries.
In specific situations, this can cause issues. To handle these situations, use fully-qualified table names. This means using an identifier that includes not only the table name, but a schema name and possibly a catalog name.
Suggested Approach
By default, Process Commander uses only the database table name to identify tables for database queries. In the following situations, this can cause issues:
- Installing two tables with the same name (such as "pr4_base") into one database instance can cause runtime errors. For example, a you may want to have two separate installations of Process Commander, both using the same database instance.
- Installing and using certain database software packages for the PegaRULES database can cause runtime errors (DB2 on IBM mainframes requires fully-qualified table names).
- Connecting to external databases that require fully-qualified table names (such as DB2 on the mainframe).
To handle these situations, use fully-qualified table names. This means an identifier that includes not only the table name, but a schema name and possibly a catalog name.
For each table in the database you associate with a Process Commander class,, complete the appropriate fields in the Data-Admin-DB-Table instance:
Because different databases have different implementations of catalog and schema names, this article cannot provide detailed instructions. Refer to vendor database documentation for details on how to set up this information.
At start-up, Process Commander needs information about the pr_base
table, to retrieve information to start. Since during the start-up process, the system hasn't yet connected to the database, this information must be stored where the system can access it : the pegarules.xml
file.
Previous topic Database tables in the PegaRULES database Next topic How to migrate work object history records that were incorrectly saved in the pr_history table