Skip to main content

Resolved Issues

View the resolved issues for a specific Platform release.

Go to download resolved issues by patch release.

Browse release notes for a selected Pega Version.

NOTE: Enter just the Case ID number (SR or INC) in order to find the associated Support Request.

Please note: beginning with the Pega Platform 8.7.4 Patch, the Resolved Issues have moved to the Support Center.

SR-B89556 · Issue 341256

fixed exception for relaystate with more than 128 characters with DB2

Resolved in Pega Version 7.4

In IDP initiated SSO, an SQL error was generated when using DB2 and the relaystate contained more than 128 characters. This was caused by DB2 validating the column length of the 'where' clause column, and those column bytes exceeding the declared length of 128. This has been fixed.

SR-B90273 · Issue 339015

Corrected assembler SQLSyntax error

Resolved in Pega Version 7.4

If an install was done with the --assembler=true option, certain generated SQLs weren't schema qualified. This resulted in a 'table not found' error and the install failed. This has been resolved by correcting the class identifier references in the cache.

SR-B94098 · Issue 341926

Oracle table metadata performance improvements

Resolved in Pega Version 7.4

Performance improvements have been added for Oracle table metadata queries.

SR-B95455 · Issue 341826

Fixed merge statement generation for long column names

Resolved in Pega Version 7.4

When the merge was generated for a column that had a long name, the generated SQL referred to the column name as a whole in one location and as a truncated name in another. This caused the query to fail. To resolve this, names will not be truncated in the case of PostgreSQL in merge statements.

SR-C11036 · Issue 353252

Extract ruleform DB schema type persists

Resolved in Pega Version 7.4

After an update was installed to enable generation to Database schema on Pega Cloud, the Extract ruleform changed automatically from 'Database Schema' output format to 'XML' even after save or check-in. Any ruleform changes were not getting persisted and always reverted to XML. . This was a missed use case in saving the BIX rule from UI, and has been corrected by resetting the output format when it is PegaCloud and the output format is schema.

SR-C6181 · Issue 348042

pyGuideID size limit increased to 128 characters

Resolved in Pega Version 7.4

The Guides task progress was not updated when tasks status was modified and the guide name was more than 32 characters. This was due to column pyGuideID having a size limit of 32, causing the extra characters to be truncated. To resolve this, the column size of pyGuideID of pc_work_guide has been increased from 32 characters to 128.

SR-C6181 · Issue 347504

pyGuideID size limit increased to 128 characters

Resolved in Pega Version 7.4

The Guides task progress was not updated when tasks status was modified and the guide name was more than 32 characters. This was due to column pyGuideID having a size limit of 32, causing the extra characters to be truncated. To resolve this, the column size of pyGuideID of pc_work_guide has been increased from 32 characters to 128.

SR-C6182 · Issue 348515

Conditional binding added to handling literals in SQL

Resolved in Pega Version 7.4

Literal values were appearing in the the SQL against PR_SYSGEN_STATIC_CONTENT, causing the query to be reassessed every time on an Oracle system and adding a new entry to the shared pool instead of using a pre-existing execution plan. In order to reduce overhead on the database caused by non-bind values, conditional binding will be implemented if PRThread context exists.

SR-C6751 · Issue 349286

Corrected duplicate table names for DB2 z/OS import

Resolved in Pega Version 7.4

When using Explicit DDL generation for DB2 z/OS, auxiliary tables were generated with the same name when deploying on single schema deployment. This happened when importing archives that created tables in both the PegaRULES and PegaDATA logical DBs when those logical DB names corresponded to the same database schema, and was due to the handling of lob table names for single schema deployments using Pega DB logical names for storing the last generated index. This has been fixed by changing to tracking the last generated index by DB2 z/OS database name / database schema name in order to prevent PegaRULES and PegaDATA lob tables from having naming collisions.

SR-C6751 · Issue 349078

Corrected duplicate table names for DB2 z/OS import

Resolved in Pega Version 7.4

When using Explicit DDL generation for DB2 z/OS, auxiliary tables were generated with the same name when deploying on single schema deployment. This happened when importing archives that created tables in both the PegaRULES and PegaDATA logical DBs when those logical DB names corresponded to the same database schema, and was due to the handling of lob table names for single schema deployments using Pega DB logical names for storing the last generated index. This has been fixed by changing to tracking the last generated index by DB2 z/OS database name / database schema name in order to prevent PegaRULES and PegaDATA lob tables from having naming collisions.

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

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us