Skip to main content

This content has been archived and is no longer being updated. Links may not function; however, this content may be relevant to outdated versions of the product.

Support Article

Simulation output definition cannot recreate table

SA-4136

Summary



When creating or updating an output definition, the table is dropped but then cannot be recreated. After the table is dropped PRPC returns with an error stating that the table does not exist and the wizard terminates.

We have checked and the user does have the required permissions to create the table. The error appears to be in the system looking for the table and failing to find it (not sure why that should prevent it from recreating the table), not in the actual creation process.

Error Messages



Table {1} does not exist in database {2}

Steps to Reproduce



A - Creating a new definition.
1. Begin a simulation output definition wizard with a database that points to the same database and schema as PegaDATA but is not called PegaDATA (this was the original issue that SR-119258 was raised to cover).
2. Select to create a dedicated database table.
3. Continue with the wizard as normal.
4. Submit the wizard. The error message should appear stating that the table does not exist.

B - Updating an existing definition.
1. Manually create the table that did not create in (A) above.
2. Open the existing simulation output definition created above by clicking on the definition's name
3. Continue with the wizard as normal.
4. Submit the wizard. The error message should appear stating that the table does not exist.

Root Cause



The root cause of this problem is defect/misconfiguration in the PRPC operating environment. Upon (re)running the output definition wizard, the process tries to delete the report class and its child artefacts like properties and report definition. It was found that the report class and some of the properties were in the previously locked ruleset version hence the wizard was not able to delete them for re-creation. Since the class and its properties were not deleted, the next step of creating underlying table fails because now the report class is structurally different to SR class.



Resolution



This issue is resolved through the following local change:
Identify the ruleset versions for all the properties/report definition present under report class and unlock them, then perform a delete of output definition. This will delete the class and its child artefacts.
Afterwards lock all the lower rulsets except the current open one, and retry to create the output definition.
In this particular case there were also custom report definitions present under that class (which were not to be deleted) so a new report class was created and that worked fine.
Framework Subject Matter Experts (SME's) confirm that this behaviour is improved in 7.1.7 and the output definition wizard picks delta of the properties changed between the current SR properties and what properties are present in the existing report class.
 

Published January 31, 2016 - Updated October 8, 2020

Was this useful?

0% found this useful

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us