Troubleshooting: Work objects incorrectly saved into the pr_other table
Summary
A developer asks:
We recently realized that all of our work objects are inadvertently being stored in the pr_other
database table, which is incorrect and prevents standard reports from operating. We want to correct this, and have created a new table based on the pc_work
schema.
- What can we do to determine if
pr_other
contains rows other than these work objects? - What is the recommended mechanism for copying all of the
pr_other
work objects into our new table?
Suggested Approach
Each row in pr_other
includes a pxObjClass column, so you could list the contents and review what kind of instances are in the table.
Moving records from pr_other
to other tables defined properly to hold Process Commander instances is quite feasible, as pr_other is defined as a very generic table.
Here is one mechanism for copying / moving the pr_other
records on your way up to production.
This approach employs SQL and the ResaverServlet tool.
- Back up the PegaRULES database. Stop the system.
- Create a new table based on the
pc_work
table. - Using an SQL tool, select from pr_other table where the pxObjClass equals a work type. Save these into your new table. The properties that are exposed as columns in the new table will be only that which was exposed in pr_other, but it's a start, as you'll get the BLOB column which contains all the data.
- Delete the moved rows from pr_other. Repeat step 3 for each work type.
- Restart the system. Add or update the Data-Admin-DB-Table instances for the work types moved, so they reference the new table you created in Step 2.
- 6. Use the the Resaverservlet servlet to populate values for the additional columns.
Here's another approach:
- Back up the PegaRULES database. Stop the system.
- Create a new table based on the
pc_work
table. - Create a SQL statement that gets you the pzInsKey values that you're targeting from pr_other.
- Cut and paste those pzInsKey values into the export servlet and extract those objects as a zip file.
- Then correct the database table mapping to save work objects into the new table
- Import the zip file.
Previous topic Troubleshooting: PSYSLOCK MAXROWS=1 causes poor performance (DB2 10 for z/OS) Next topic Troubleshooting: database error ORA-00904: Invalid Identifier on startup in new Oracle installation