OBJ-SAVE in PRPC 6 and Pega 7 versions

Is there any difference in Pega 6 and Pega7 for the obj-save's underlying platform sql query to save the objects to the database?

If yes, what is it?

Appreciate any inputs on this.

***Updated by moderator: Lochan to add Categories***

**Moderation Team has archived post**

This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.

Correct Answer
October 15, 2015 - 5:29am


I don't think there is any difference. Have you noticed anything ? As far as I know, the OBJ-SAVE method is still behaving the same way on Pega 7.


Keep up to date on this post and subscribe to comments

October 15, 2015 - 5:29am


I don't think there is any difference. Have you noticed anything ? As far as I know, the OBJ-SAVE method is still behaving the same way on Pega 7.

October 15, 2015 - 5:58am

If you have access to both versions, couldn't you turn on Tracer or perform a DBTrace to see/compare the underlying SQL?

Kip | Community Moderator | PEG

October 15, 2015 - 4:44pm

Is there an easy way to turn on db-level tracing independent of prpc to really see everything the obj-save is doing to the db ?  /Eric

October 16, 2015 - 6:56am
Response to ericosman_GCS
Kip | Community Moderator | PEG

October 16, 2015 - 9:57am

Hi kip.  Thanks for that reference.  It doesn't seem to mention the global db trace feature of the SMA tool, so if I find a good reference to that, I'll mention it here too.  /Eric

October 16, 2015 - 3:43pm

if not wrong, from my learning's...

there is a sporadic/concern on the property pxUpdateDateTime not being updated when Obj-Save either with Write now or followed by Commit methods are issued.

Because of the incorrect pxUpdateDateTime value, at times the updates performed via Obj-Open-By-Handle on the workobject are lost.

from Pega 7.1.8/7.1.9 two columns were introduced to OOTB PRPC tables pxSaveDateTime & pxCommitDateTime to track the actual save and commit to the database.

The two column values will be updated by engine itself. So, when an Obj-Save is issued the property pxSaveDateTime would hold the save time.

Please share your observations/comments, if wrong!

Thank you!


October 16, 2015 - 5:12pm

There are rumors around about pxUpdateDateTime but they are false.

The truth is, if you obj-open-by-handle with locking and successfully get the lock, and you write a value in your own property X, then obj-save and commit, when you read back the record later again with locking, if no one else has touched property X, you should see exactly the value you wrote there.  It doesn't matter what you do to pxupdateDateTime.

However, a bug was fixed recently for Pega 7.1.7.  The symptom was that if one requestor does obj-open-by-handle on a record with locking just as another requestor has just unlocked it, there is the danger that the one doing the new locking will get stale data on their page.

If you have evidence that this is happening to you, you may put in a ticket requesting HFix-24300 .  /Eric

October 16, 2015 - 5:23pm
Response to ericosman_GCS

Thank you Eric for the correction.

November 6, 2015 - 9:27am

With respect to underlying DB queries, I have a done quick test on PRPC 61SP1 and Pega 717 for inspecting the underlying SQL query for Obj-Save method.

On 61SP1 it’s an UPDATE query on the work table with the corresponding input values.

On Pega 717 it’s a MERGE query into the work table with corresponding inserts.

November 22, 2015 - 3:04pm
Response to Harish_GCS

Thank you Harish!