Question
Ford Motor Company
US
Last activity: 1 Aug 2017 10:41 EDT
Wrong date getting insert into pr_sys_locks table on the pxExpireDateTime value
Hi,
We have agent processing, during the agent processing we see the pxExpireDateTime value getting inserted wrongly, due to that those agents are getting failed.
"seeing couple of instances where DMS Agents are getting errored out while they are trying to update System lock. In following example system is changing the pxExpireDateTime from ‘<2017-03-06 15:20:45.84>’ to <0001-03-06 15:20:45.923> .
2017-03-06 14:50:45,953 [.PRPCWorkManager : 3] [ STANDARD] [rdOWSOneApp:01.01.05] (nternal.access.LockManagerImpl) ERROR - Problem updating the lock for "XXXX CF-14762138"
com.pega.pegarules.pub.database.DatabaseException: Problem updating the lock for "XXXX CF-14762138": code: 242 SQLState: S0003 Message: The conversion of a datetime2 data type to a datetime data type resulted in an out-of-range value.
From: (B3D78F747D7D218B452DFDC81D31A5FE4)
SQL: update pr_sys_locks set pxExpireDateTime = ?, pxLockHandle = ?, pxOwnerId = ?, pxSystemName = ?, pxSystemNode = ?, pxUpdateDateTime = ?, pxUpdateOpName = ?, pxUpdateOperator = ?, pxUpdateSystemID = ?, pxUserHost = ? where pzInsKey = ? and pxOwnerId = ? and pxExpireDateTime = ?
Hi,
We have agent processing, during the agent processing we see the pxExpireDateTime value getting inserted wrongly, due to that those agents are getting failed.
"seeing couple of instances where DMS Agents are getting errored out while they are trying to update System lock. In following example system is changing the pxExpireDateTime from ‘<2017-03-06 15:20:45.84>’ to <0001-03-06 15:20:45.923> .
2017-03-06 14:50:45,953 [.PRPCWorkManager : 3] [ STANDARD] [rdOWSOneApp:01.01.05] (nternal.access.LockManagerImpl) ERROR - Problem updating the lock for "XXXX CF-14762138"
com.pega.pegarules.pub.database.DatabaseException: Problem updating the lock for "XXXX CF-14762138": code: 242 SQLState: S0003 Message: The conversion of a datetime2 data type to a datetime data type resulted in an out-of-range value.
From: (B3D78F747D7D218B452DFDC81D31A5FE4)
SQL: update pr_sys_locks set pxExpireDateTime = ?, pxLockHandle = ?, pxOwnerId = ?, pxSystemName = ?, pxSystemNode = ?, pxUpdateDateTime = ?, pxUpdateOpName = ?, pxUpdateOperator = ?, pxUpdateSystemID = ?, pxUserHost = ? where pzInsKey = ? and pxOwnerId = ? and pxExpireDateTime = ?
SQL Inserts: <0001-03-06 15:20:45.923> <XXXX CF-14762138> <B3D78F747D7D218B452DFDC81D31A5FE4> <systemName> <f9d23fcdc1330deeb5d6be5589242aa7> <2017-03-06 14:50:45.923> <Agent(XXXX-ClaimFile.ProcessBatchClaimCovers)> <System> <systemName> <> <XXXX CF-14762138> <B3D78F747D7D218B452DFDC81D31A5FE4> <2017-03-06 15:20:45.84>
Caused by SQL Problems.
Problem #1, SQLState S0003, Error code 242: com.microsoft.sqlserver.jdbc.SQLServerException: The conversion of a datetime2 data type to a datetime data type resulted in an out-of-range value.
Did anyone faced this kind of issue?
Regards,
Anandh
***Updated by moderator: Lochan to add Categories***
PEG
US
The error message you see:
com.pega.pegarules.pub.database.DatabaseException: Problem updating the lock for "XXXX CF-14762138": code: 242 SQLState: S0003 Message: The conversion of a datetime2 data type to a datetime data type resulted in an out-of-range value.
is just a result of trying to insert the date that is in the year 0001. (It happens for all years previous to 1753 for arcane reasons.) You can ignore it -- when you figure out why you've lost all the digits in the year, you will have eliminated the above error message.
The extension of the date time is an automatic operation inside the Pega Engine. I can't imagine anything that would result in the year characters being wiped out.
What version are you running of PRPC? At a certain point there was a hotfix which eliminated the extension of the expiration time as it turns out it is almost never needed and just imposes unnecessary overhead. Depending upon your release, there may be a hotfix for this.
PEG
US
I just had a thought. What is the lock timeout interval for the lock in question? Perhaps when extending the timeout value there is a corrupt or nonsensical value being added, resulting in an exception and a zero-ing out of the year? It's a stretch, but.....
PEG
US
I think you want to create an SR for this. I'm not able to find anything like this in the knowledge base, nor can I come up with an explanation as to how this might be happening. It sounds like a bug to me.
Pegasystems Inc.
IN
Hi Anandh,
Feel free to let us know the SR number details so that we can notify it along with the issue description for tracking purposes.
Thanks!