Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

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.

Troubleshooting: Work objects incorrectly saved into the pr_other table

Updated on September 13, 2021


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.

  1. What can we do to determine if pr_other contains rows other than these work objects?
  2. 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. 

  1. Back up the PegaRULES database. Stop the system.
  2. Create a new table based on the pc_work table.
  3. 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.
  4. Delete the moved rows from pr_other. Repeat step 3 for each work type.
  5. 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. 6. Use the the Resaverservlet servlet to populate values for the additional columns.

Here's another approach:

  1. Back up the PegaRULES database. Stop the system.
  2. Create a new table based on the pc_work table.
  3. Create a SQL statement that gets you the pzInsKey values that you're targeting from pr_other
  4. Cut and paste those pzInsKey values into the export servlet and extract those objects as a zip file. 
  5. Then correct the database table mapping to save work objects into the new table
  6. 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

Have a question? Get answers now.

Visit the Support 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. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us