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.
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.