Question
Cognizant
IN
Last activity: 24 Jun 2024 1:27 EDT
if we have obj save with write now and commit statement in an activity then why obj save with writenow changes are not reflecting in the database?
I am opening a student ID record and doing a property set for class property
So first time property set class= 111,after that i am doing an obj save (without write now) and giving another property set class=112 then calling commit so here class value is setting to 111 in data type(but in tracer we can see class value as 112)
Now second time I am using property set class= 111,after that i am doing an obj save (without write now) and giving another property set class=112 then again calling obj save (with write now checked) and calling commit so here also class value is setting to 111 in data type(but in tracer we can see class value as 112)
Why is this happening?
Please find the screenshot attached
-
Reply
-
Prateek Patnaik -
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Accepted Solution
Updated: 24 Jun 2024 1:27 EDT
Eclatprime Digital Private Limited
IN
- In first scenario : You are using property set class= 111,after that i am doing an obj save (without write now) and giving another property set class=112 then again calling obj save (with write now checked) and calling commit so here also class value is setting to 111 in data type(but in tracer we can see class value as 112)set class= 111,after that You are doing an obj save (without write now) that time it will be in deferred save and then giving another property set class=112 then calling commit so here class value is setting to 111 in data type(but in tracer we can see class value as 112). Why its not setting to 112n again in DB because it will pick all the deferred save , You have 111 in deferred save because of obj save mentioned after that property set but 112 still in tracer because property got set but still no save or deferred save happened with that 112 , that is why you can see 112 in tracer but can't save to data type because commit will not pick 112 first it will pick 111 because of deferred save.
- In second scenario : I am using property set class= 111,after that you are doing an obj save (without write now) and giving another property set class=112 then again calling obj save (with write now checked) and calling commit so here also class value is setting to 111 in data type(but in tracer we can see class value as 112) , This is happening because of commit overriding the data of obj-save with writenow , if commit is not there it will show you 112 in DB .
Lantiqx Systems India Private Limited
IN
Hi @TanyaS58,
In the first scenario, when you set the values without giving write now it will go and store in the deferred queue, and when you give commit the first property set value(i.e, 111) gets saved in the database(even though you have set the property value 112 as you have not given obj-save value wont even go to deferred queue so it wont get saved in the database table but it will be updated in tracer as well as clipboard as it is a step which is been executed in the activity )
In the second scenario, as you have given write now the value will be saved directly into the database table i.e, 112
Regards,
Prasad
Cognizant
IN
@Prasad Reddy Muddam but in the second scenario what I am doing is first property set class=111 then obj save without writenow then again property set class =112 then giving obj save with write now and after this calling commit so still it’s not reflecting class as 112 instead in the database it’s showing 111,but in the tracer it’s showing 112 why so?
Pegasystems Inc.
IN
@TanyaS58 - Writenow enabled will add the data immediately to data base.
Write now disabled will be placed in deferred queue adds this page to the set of deferred-write pages for this requestor. The actual database write operation is deferred until a later execution of the Commit method in the same Thread.
As per the document ->
First 112 will be added in DB and because of commit step 111 will be coming overriding the previous value. Test the changes by commenting out commit step.
Thank you.
Cognizant
IN
@Priyanka Boga oh okay so as in second scenario I am doing property set class=111 without writenow and then later at the time of commit this will override the change done by obj save with writenow i.e 112 right?
Accepted Solution
Updated: 24 Jun 2024 1:27 EDT
Eclatprime Digital Private Limited
IN
- In first scenario : You are using property set class= 111,after that i am doing an obj save (without write now) and giving another property set class=112 then again calling obj save (with write now checked) and calling commit so here also class value is setting to 111 in data type(but in tracer we can see class value as 112)set class= 111,after that You are doing an obj save (without write now) that time it will be in deferred save and then giving another property set class=112 then calling commit so here class value is setting to 111 in data type(but in tracer we can see class value as 112). Why its not setting to 112n again in DB because it will pick all the deferred save , You have 111 in deferred save because of obj save mentioned after that property set but 112 still in tracer because property got set but still no save or deferred save happened with that 112 , that is why you can see 112 in tracer but can't save to data type because commit will not pick 112 first it will pick 111 because of deferred save.
- In second scenario : I am using property set class= 111,after that you are doing an obj save (without write now) and giving another property set class=112 then again calling obj save (with write now checked) and calling commit so here also class value is setting to 111 in data type(but in tracer we can see class value as 112) , This is happening because of commit overriding the data of obj-save with writenow , if commit is not there it will show you 112 in DB .