Getting Error while committing update set from Xanadu version instance to Washington DC

priyanka_Boppi
Tera Contributor

Please advise for the below error getting while committing update set from Xanadu version Dev instance to UAT version of Washington DC

Commit log error :Table 'sys_es_latest_script' does not exist

 

1 ACCEPTED SOLUTION

Mark Roethof
Tera Patron
Tera Patron

Hi there,

 

That's a valid error and one of the examples why you should not promote development from a higher release to a newer release.

 

sys_es_latest_script is the table that keeps track which scripts have the ES12 toggle on. This table was introduced in the Xanadu release, so won't be on Washington DC.

 

If you did not apply ES12 in your new/updated script, than you could consider ignoring the error.

 

Kind regards,

 

Mark Roethof

Independent ServiceNow Consultant

10x ServiceNow MVP

---

 

~444 Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

LinkedIn

View solution in original post

4 REPLIES 4

Mark Roethof
Tera Patron
Tera Patron

Hi there,

 

That's a valid error and one of the examples why you should not promote development from a higher release to a newer release.

 

sys_es_latest_script is the table that keeps track which scripts have the ES12 toggle on. This table was introduced in the Xanadu release, so won't be on Washington DC.

 

If you did not apply ES12 in your new/updated script, than you could consider ignoring the error.

 

Kind regards,

 

Mark Roethof

Independent ServiceNow Consultant

10x ServiceNow MVP

---

 

~444 Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

LinkedIn

Ankur Bawiskar
Tera Patron
Tera Patron

@priyanka_Boppi 

I agree with Mark.

Regards,
Ankur
Certified Technical Architect  ||  9x ServiceNow MVP  ||  ServiceNow Community Leader

Dr Atul G- LNG
Tera Patron
Tera Patron

Hi @priyanka_Boppi 

 

You are committing the changes at lower instance from higher instance, it means there are few changes / configurations which are not same in both instance and these error can come. you can ignore this but it may impact your system/ working or  bring the both instance on same level. 

*************************************************************************************************************
If my response proves useful, please indicate its helpfulness by selecting " Accept as Solution" and " Helpful." This action benefits both the community and me.

Regards
Dr. Atul G. - Learn N Grow Together
ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
Topmate: https://topmate.io/atul_grover_lng [ Connect for 1-1 Session]

****************************************************************************************************************

CooperCarroll
Tera Contributor

I agree with Mark that Promoting code from pre-prod instances that are on a higher version than Prod is a bad idea and should be avoided.   However if exigent circumstances interpose... 

I can confirm that after ignoring this error for catalog_script_client and sysauto_script  entries with the ES12 toggle set to false that: 1) Catalog client scripts function properly in an environment where the sys_es_latest_script does not yet exist.  2) The scheduled jobs also run correctly.

YMMV.  Test it thoroughly before promoting: Promote to a pre-Xanadu environment and accept the remote update after previewing and getting the error about the sys_es_latest_script table being missing.   Test everything listed in the sys_es_latest_script table.  Do not promote is anything in your update set has a "Use ES latest" value of true.  You will need to go back to Dev and unset that on the script and potentially rewrite your code to use legacy JavaScript.  BTW You will not find sys_es_latest_script contained the target name or name field in the sys_update_xml table.  

After Prod is upgraded, move the records from sys_es_latest_script for whatever you have promoted to Prod from your Xanadu pre-prod environment to the sys_es_latest_script table in Prod.

Use this process at your own risk.  As prescribed by Mark: Not best practice.  Don't do this.