Saving as of existing calendar instance not allowing to save in 8.5.2 version
While saving as of existing calendar instance with New start date & Existing name in pega 8.5.2 it always saying "The timezone specified here conflicts with an earlier instance of this calendar."
If I am creating a new calendar instance with New start date & Existing name, then also it is giving the same error.
Please suggest a solution for this issue.
Accepted Solution
Updated: 16 Nov 2021 12:16 EST
Atos
IN
Updated: 11 Nov 2021 7:42 EST
Ernst & Young LLP
MT
Th error is coming from OOTB activity Data-Admin-Calendar.Validate (Step 4 - 2nd Pre-condition).
It happens when at least one of the older/existing instances of the same calendar has a standard time zone that is different from the new calendar instance.
Can you verify the same? And, also trace this rule at the time of save as?
Thanks
Atos
IN
@Nirmalya.SenSharma thank you for quick reply.
All the existing instances of the same calendar has a standard time zone as the new calendar instance which i am trying to keep.
Ernst & Young LLP
MT
@VaseemS8 Have you tried to trace that rule to understand - 1. if this rule indeed returning that error, 2. If it does then why?
Atos
IN
I have traced the rule and it's still returning "StandardTimeZone must stay".
But, identified that the pyStandardTimeZone value for existing Calendar instances is showing null in the database table of Calendar, even though the value is selected from the dropdown with Europe/London timezone for all existing instances(pyStandardTimeZone is blank in tracer pages)..
Also, while doing Save as or Creating new Calendar rule the pzInsKey is different for both existing and new one.
Please find attachment for reference.
Ernst & Young LLP
MT
Has it started happening after any recent PEGA platform upgrade? Either way, I think you should submit a bug report to PEGA support.
A quick solution to the problem is to -
- Private edit that Validate activity to comment/disable step 4.
- Save as the new calendar instance (This should work)
- Save all the older instances of the same calendar.
This will hopefully populate that column with timezone data on table.
If it does, then -
- Discard the private edit of that Validate activity rule.
- Save all the instances of the calendar to verify that there is no longer any data corruption.
If you are planning to try this work around -
- Quickly create a product containing all instances of that calendar (this will act as backup)
- Try this only in Dev env, and not directly in any higher env.
Accepted Solution
Updated: 16 Nov 2021 12:16 EST
Atos
IN
Hi,
Thank you very much for the information, now the timezone column populating the values in DB table for older and new calendar instances with the above steps. We are in a way to discuss with our team for further steps.
SCB
MY
@Nirmalya.SenSharma - Thanks for your solution..working fine
HCL Technologies
IN
The simple solution for above issue is Edit some value in existing calander and save it. Now create new one by save as the existing one. it should work now.
@Nirmalya.SenSharma
Hi,
Thank you very much for the information, now the timezone column populating the values in DB table for older and new calendar instances with the above steps. We are in a way to discuss with our team for further steps.