Fix Script updated all records to point to the same record

[Matt Jones3]

I can't tell if I did something dumb here, or if ServiceNow did...

What I'm trying to accomplish is to create a pivot table that shows counts broken down by created month.   You can do this on other types of charts, but as far as I can tell you can't OOTB on a pivot chart.

To be able to break down data this way I created a u_created_month and u_created_year on the Task table, and a business rule that sets these values when a new record is inserted.  Ok, so far so good...except I _also_ want to set these values for existing records.

So, I wrote the following as a Fix Script:

initCreated();

function initCreated() {
	var gr = new GlideRecord('task');
	gr.addQuery("active", true).addOrCondition("active", false);
	gr.query();
	
	while (gr.next()) {
		gs.info("Currently updating: " + gr.getValue("number"));
		var createdDate = new GlideDate();
		createdDate.setValue(gr.getValue("sys_created_on"));
		gr.setValue("u_created_month", createdDate.getByFormat("MMM"));
		gr.setValue("u_created_year", createdDate.getByFormat("YYYY"));
		gr.update();
	}
}

Fairly straightforward, so I thought.  After running the script, _every_ Task record in our (thankfully Dev!) instance is now pointing to the same record:

What the heck!  How did this happen, and is there a way to recover, short of a clone-down?

Looking the log, it was definitely hitting different records along the way:

*** Script: Currently updating: SCTASK0011079
*** Script: Currently updating: RITM0015145
*** Script: Currently updating: SCTASK0017081
*** Script: Currently updating: GAPRV0010414
*** Script: Currently updating: SCTASK0012336

But after the script completed, none of these records seem to exist anymore.  I'm so confused, and have no idea what happened...

[Brad Bowman]

Hi Matt,

Strange indeed.  Nothing in your Fix Script suggests this outcome.  After you clone (no other good recovery from this comes to mind), I can suggest a couple of things for the next attempt.

1. What is the point of your addQuery line?  All tasks are either active true or false, so this seems unnecessary, but otherwise not harmful.
2. Add a line prior to gr.query() to limit the records that will be returned (and updated) by the script (temporary - comment out/remove after testing)   

    gr.setLimit(10);

3. Add a line prior to gr.update() to ensure that no other Business Rules run when this record is updated.

   gr.setWorkflow(false);

[Matt Jones3]

Yeah, so that was another dumb thing...  Before adding the (admittedly silly) query, the script was getting stuck in an infinite loop.  An earlier version I had something like: 

	var gr = new GlideRecord('task');
	gr.query();

	var counter = 0;	
	while (gr.next() && counter < 10) {
		gs.info("Currently updating: " + gr.getValue("number"));
...
		counter++;
	}

and the log message would just show the same record 10 times.  I don't understand why.  Adding the query seemed to fix...but obviously not completely.

I hadn't heard of the .setWorkflow(false), that's handy.

I did run across the .setLimit(), and was using that for smaller scale testing which I thought was working before removing and running "for real"

[-O-]

I wonder if changing the variable name from gr to something else would "fix" this 🤔

I mean without using .setWorkflow() - just out of curiosity.