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-D78274 · Issue 544092

Handling added for dual privileges with MSSQL

Resolved in Pega Version 8.2.7

After setting up dual privileges, the Admin user was able to create a table but the base user received an "insufficient privileges" error. Investigation showed this was an issue when using MSSQL: the generated grant statements used the server login name as the user in the grant statement, instead of the database user. For all other databases, the username passed into the connection is the correct user to use for grants. Only MSSQL has a distinction between this connection user name (the login) and the database user, and since the login did not exist in the user table, the grant failed. To resolve this, when MSSQL is used, the system will fetch the underlying database user when determining the user for grant statement generation.

SR-A89295 · Issue 258931

Result count option added to Campaigns for performance tuning

Resolved in Pega Version 7.2.2

Slowness was seen when launching and running Field Marketing Campaigns. This was an issue with loading results using pxRetrieveReportData with paging enabled, as it fetched the total result count for each page. To resolve this, an option has been added to pxRetrieveReportData to disable fetching of total result count. This is available as Embed-QueryInputs property of type TrueFalse called 'pyReturnResultCount' when running report using pxRetrieveSearchData's pyReportParamPageName Parameter.

SR-A98103 · Issue 266253

Scheduled recurring Purge/Archive set to reuse specified start time

Resolved in Pega Version 7.2.2

When scheduled to run every day at a particular time, the Purge/Archive function started later each time. This was due to the function using the Agent running time for the rescheduling, starting the next day at the time it ended. The function has now been modified to use the customer-specified start time instead of calculating the Agent time.

SR-A86228 · Issue 256027

Documentation corrected for connection properties with WAS 8.5.5.7 and MSSQL 2014

Resolved in Pega Version 7.2.2

The case specified in the install guide for including the "SelectMethod" and "SendStringParameterasUnicode" connection properties was incorrect, causing poor performance in the import process when using WAS 8.5.5.7 and MSSQL 2014. The documentation has been corrected.

SR-D62754 · Issue 559848

PrepareResponse updated to explictly close Input Handler

Resolved in Pega Version 8.2.7

When using prpcServiceUtils to export a product in a Windows+Weblogic environment, attempting to export repeatedly using the same archiveName with the intention of overwriting the older product with the newer one in the ServiceExport directory failed with a FileNotFoundException. Investigation showed that the product file that was created by the pzExport REST call was not being released by the Weblogic File Handler process. Due to this, the next time the call was invoked the system tried to create the same file in the directory but failed due to the earlier File handle lock. To resolve this, the system has been updated to explicitly close the InputStream using try-with-resources.

SR-A76628 · Issue 255871

Forced logging type changed to avoid incorrect alerts from WebLogic

Resolved in Pega Version 7.2.2

When using PRPC with WebLogic, server restarts were generating the notice that Emergency messages were present in the Server console log file. This was due to WebLogic treating logs with level greater than 1000 as emergency while PRPC was using level greater than 1000 for forced logs (infoForced and warnForced) to ensure that forced logs were not skipped in any log level setting except for level OFF. As WebLogic does not have any equivalent for forced logging, it interpreted this as an emergency. This behavioral conflict has been resolved by changing the PRPC logs from infoForced to info.

SR-A96149 · Issue 262711

Forced logging type changed to avoid incorrect alerts from WebLogic

Resolved in Pega Version 7.2.2

When using PRPC with WebLogic, server restarts were generating the notice that Emergency messages were present in the Server console log file. This was due to WebLogic treating logs with level greater than 1000 as emergency while PRPC was using level greater than 1000 for forced logs (infoForced and warnForced) to ensure that forced logs were not skipped in any log level setting except for level OFF. As WebLogic does not have any equivalent for forced logging, it interpreted this as an emergency. This behavioral conflict has been resolved by changing the PRPC logs from infoForced to info.

SR-A95888 · Issue 270679

MSSQL upgrade indexing updated

Resolved in Pega Version 7.2.2

After upgrade, an index was missing. Analysis showed the create index statement was using an include clause to add pzInskey in the index column list, which did not work on MSSQL because the DatabaseMetadata interface for the MSSQL JDBC driver did not return the columns in the INCLUDE list when a call to getIndexInfo was made. This resulted in a mismatch of the column list available in pr_changelog. This has been fixed, and automation has been added to detect this mismatch in the future.

SR-A103064 · Issue 270247

Schema Change Tracking query performance improvements

Resolved in Pega Version 7.2.2

A query which was used in Schema Change Tracking (Designer Studio -> System -> Database -> Schema Change Tracking) was causing high CPU usage. This was due to the query having a full table scan which was using Information_schema, and the query has been rewritten for better efficiency.

SR-A76982 · Issue 253572

pyRuleSet added to fields of listview filter if not explicitly set

Resolved in Pega Version 7.2.2

Data Instances were not included in product jar when a Developer included ListView Rule with certain Filter criteria in Product Rule to extract Data Instances. When a listview filter is added to RAP, the instances returned by listview must be packaged by Rule-Admin-Product, but this was not happening if the listview filter did not have pyRuleSet in its fields. When a pyRuleSet is not included in listview, records returned by listview filter will be treated as invalid by export process in InstanceInfo class. To avoid unexpected behavior, .pyRuleSet will now be added to fields of listview filter if it doesn't exist.

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