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: Microsoft SQL Server rounds datetime to nearest 1/3 of a hundredth of a second

Updated on September 25, 2019


If you save an item with a datetime column in Microsoft SQL Server (MSSQL), such as pxUpdateDateTime, and read back the value, you may get a different value.

For example, the PegaSaveDetect utility sent false information indicating that an older version of a work object was overwriting a newer one. The utility was confused because the pxUpdateDateTime value in the MSSQL column showed a value slightly newer than the pxUpdateDateTime on the PRPC Clipboard page of the new data being written. The newer value was caused by the MSSQL rounding of the datetime value to the nearest 1/3 of a hundredth of a second.


Microsoft SQL Server rounds the datetime value to the nearest 1/3 of a hundredth of a second. This means that, regardless of the millisecond value in your DateTime property, the millisecond part of the value stored in the exposed column is rounded to the nearest .xx0, .xx3, or .xx7 value. On a second read-back, specify the asterisk wildcard character “*” to ask for all columns. PRPC reads from the BLOB instead of the individual columns, giving the original DateTime property value instead of the rounded one.

There are many ways to see this. One is to save a work object using the Obj-Save method with Write Now checked on a PRPC application running on the Microsoft SQL Server database type. Then use the executeRDB API to read back the pxUpdateDateTime value. If your original value did not have a millisecond value ending in 0, 3, or 7, the value read back will not agree with your original and, in fact, can be either a bit lower or higher.

Suggested Approach

If you use the executeRDB API to read directly from the database and you observe an unexpected discrepancy of less than 3 milliseconds between the datetime column value and your PRPC clipboard value, you can do a second read using “*” (the asterisk wildcard character) to ask for all columns. This causes PRPC to read from the BLOB instead of the individual columns, giving the original DateTime property value instead of the rounded one.

Additional Information

PegaRULES Database Overview


SQL Server datetime and smalldatetime

  • Previous topic Troubleshooting: InvalidParameterException, database column aliases not found after JDBC driver update (DB2 LUW driver v4.12.55)
  • Next topic Troubleshooting: Out-of-the-box triggers reference pr_sys_locks table impacting PRPC performance (HFix-4229, HFix-4349)

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