---
original_url: "https://jace.pro/blog/batching-updates-gliderecord-and-glidemultipleupdate/"
format: markdown
ai_optimized: true
---

Batching Updates (GlideRecord and GlideMultipleUpdate)- # Batching Updates (GlideRecord and GlideMultipleUpdate)

November 1, 2024 [servicenow ](/tags/servicenow/)[gliderecord](/tags/gliderecord/)

  Enable AI AnimationUpdate Many does not need `.query()`
Update Many does not work with `.chooseWindow()` or `.setLimit()`

## [Glass’ Putan Post](#glass-putan-post)

[Updating Multiple Entries | Glass 'putan with Service-Now (wordpress.com)](https://glassputan.wordpress.com/2012/01/26/updating-multiple-entries/)

This does not work for inherited tables. For example if you inherit from task (incident, change) and try to use a field on task in your query clause, you will end up updating every record

How to do it:
Normally when iterating trough a list of records, you would create a GlideRecord object, execute a query, iterate though each return and update the records one at a time.

`try {
   var mu = new GlideRecord("sys_user");
   mu.addQuery("column_to_search","value_to_search_on");
   my.query();
   while(mu.next()) {
      mu.column_to_set="new_value";
      mu.update();
   }
} catch(xx) {
  gs.log("Exceptionht: " + xx.message);
}`Using this method also has a strong chance of timing out with larger data sets and face it, this is great for those paid by the hour, but in our situation where extra time is our time, there’s a better way to do it.

`try {
   var mu = new Packages.com.glide.db.MultipleUpdate("sys_user  mu.addQuery("column_to_search","value_to_search_on");
   mu.setValue("column_to_set", "new_value");
   mu.execute();
}
catch(xx) {
	gs.log("Exceptionht: " + xx.message);
}`What this does:
This package basically generates a SQL command that’s executed behind the scenes.
In this case it would look something like:

`update sys_user set column_to_set="new_value" where column_to_search="value_to_search_on"`
Disclaimer:
These tips and tricks are to give you more power to handle the tasks that you may face developing and maintaining the Service-Now application. Use them at our own risk, and by all means use them in a “sand box” environment first. With great power, comes great responsibility.

## [Community Post - How to do a mass ‘Update All’](#community-post-how-to-do-a-mass-update-all)

[Solved: Re: How to do a mass ‘Update All’ - ServiceNow Community](https://www.servicenow.com/community/developer-forum/how-to-do-a-mass-update-all/m-p/1462601/highlight/true#M119527)

[Updating Multiple Entries | Glass 'putan with Service-Now](https://glassputan.wordpress.com/2012/01/26/updating-multiple-entries/)

Because of its age it does use an old package call.   Here is an out of the box example of its use with import sets when you click “reprocess”.   Make sure you use the new `GlideMultipleUpdate` API call instead.

`var mu = new GlideMultipleUpdate("sys_import_set_row");
mu.addQuery("sys_import_set", current.sys_id);
mu.setValue("sys_import_state", "pending");
mu.execute();`## [Community Post - updateMultiple() doesn’t update system fields](#community-post-updatemultiple-doesnt-update-system-fields)

[Re: updateMultiple() doesn’t update system fields … - ServiceNow Community](https://www.servicenow.com/community/now-platform-forum/updatemultiple-doesn-t-update-system-fields-like-sys-updated-on/m-p/2616035/highlight/true#M190371)

Matthew Watkins
I’m surprised that this isn’t documented anywhere else, but it seems this is a little known platform behavior. In almost all cases, `GlideRecord.updateMultiple()` is going to execute as an iterative update in the background (i.e. 1,000 records updated results in 1,000 UPDATE statements in SQL since we basically just loop over all the matching records and call `GlideRecord.update()` on them). During the iterative update operation, the business logic will execute that records the sys_ field changes (this is in the Java layer), but there is an exception. If you run `GlideRecord.updateMultiple` on a table that DOES NOT meet any of the criteria at the bottom, then it will not run as an iterative update, it will run as [GlideMultipleUpdate](https://www.servicenow.com/community/developer-forum/how-to-do-a-mass-update-all/m-p/1462600) (which I don’t think we’ve ever officially documented) and it will execute a single database operation (i.e. 1,000 records updated results in only 1 UPDATE statement in SQL!). Another side effect of `GlideMultipleUpdate` is that it doesn’t update the sys_ fields unless you explicitly tell it to.

Table is text indexed

- Table is audited

- `SetWorkflow(false)` has not been called and table or it’s children have any before or after update business rules

- Table has any restricted cascade rule

- Table has any currency fields

- Table has the attribute “`iterativeDelete`” set true

- Table has the attribute “`update_synch`” set true

- Table is registered with a Record Watcher

- Table is replicated by IDR

- Operation is against the `sys_administrative_script_transaction` table

---
[View this page on GitHub](https://github.com/jacebenson/jace.pro/tree/main/./src/posts/2024/2024-11-01-batching-updates-gliderecord-and-glidemultipleupdate.md).

[Batching Updates (GlideRecord and GlideMultipleUpdate)](https://jace.pro/blog/batching-updates-gliderecord-and-glidemultipleupdate/) [Jace Benson](https://jace.pro) ![Jace Benson](https://jace.pro/icon-512x512.png)

---

*This content is from Jace Benson's ServiceNow and tech blog at jace.pro*
*Original post: https://jace.pro/blog/batching-updates-gliderecord-and-glidemultipleupdate/*