.update() does not work and returns null

[Yuriy7]

Often fails to update the record fields

var req_parent = new GlideRecord('sc_req_item');

req_parent.get(current.request_item.sys_id)

req_parent.state = 3;

// then I try to update the record

var req_id = req_parent.update();

gs.log("##### For " + req_parent.number + " - success. ID of the updated record: " + req_id);

This code does not work in a small number of cases (maybe 1-5%)

In the log, I see this message:

"##### For RITM4756385 - success.  ID of the updated record: null"

Although in most cases I see the return value here - the sys_id of records.

Who faced something similar? What diagnostics can be done to identify the cause?

[Yuriy7]

Hi! There are no business rules prohibiting set the state to 3. As I already wrote, failures occur in 1-5% of cases, at 95% everything works as it should.
But I tend to the version that there really is some contradiction in the system about set the state to 3. In many problem cases I noticed that almost simultaneously with my code (within 30 seconds) another update of this record occurred (for example, an employee updated this record through the form and almost at the same time my business rule worked - the rule that tried to update set the state to 3 and returned me null).

But there were also cases when there was no parallel update of the record. Perhaps the change was hampered by something else.

[DirkRedeker]

Hi

I mean, I understand, that you can change the value in most case to 3.

Maybe it is dependend, on other fields, or from the state value before.

Maybe it is allowed to update from 1 and 2 to 3, and

maybe it is prevented to update from 4 and 5 to 3.

That's what I was asking for. Maybe you need to investigate about the records failing, and find out, what they may have in common compared to the records succeeding.

I cannot imagine a technical issue on the instance, to be honest.

Your idea about the case, that users may change the record "meanwhile" is very unlikely. At least it depends on the load of the instance. Are there actually lots and lots of changes of records per minute performed by users?

Just let me know, what do you think?

BR

Dirk

[Yuriy7]

I understand what you write.
But there are no problems in the recording itself - after this failure on the same recording, I make the same changes and update goes well.
I admit that there may be some business rule that sometimes works at the time of recording and makes it difficult to update the state. But I can't find it. I somehow need to check which business rules worked at the time of failure in order to view them in detail.
But I do not know how to do it.
Regarding the frequency of changes in the record - it does not happen often. In the change history, I found that the record was updated 30 seconds before the crash. In my opinion, this is a very big time to prevent the upgrade. In addition, it is only part of the failure cases. There are records that are not updated at the same time.

[DirkRedeker]

Hi That sounds really interesting, and I would like to know the cause.... How many records are you loop in one execution of the job. Have you heard about 'phantom' records. I just know that from MS-SQL. That happens, when you select a number of records, which may change or even be deleted during a transaction. In this case, they appear in your dataset queried, but they are not there anymore in the database. That means, you cannot access them in the database anymore. They are just in your resultset. Maybe the problem you face is different.... Maybe the 5-10% of the records are those, that did not meet the criteria, when you queried the DB, and the ones with null value have disappeared. You could investigate about that by writing a log for the failed records and check afterwards, if exactly those records still exist. Hope it is clear what I am trying to explain. Just let me know. BR Dirk

[The SN Nerd]

Exception handling isn't going to help in this situation.

I think you will find either a data policy or business rule is preventing your update.

Regardless, you may want to implement some standard error checking.

See code below:

var req_parent = new GlideRecord('sc_req_item');
var recordFound = req_parent.get(current.getValue('request_item')); //Always check for success
var req_id, output;

if (recordFound) {

   req_parent.state = 3;
   req_id = req_parent.update();
   var updateSuccessful= (req_id != null); //update returns null if update fails


   if (updateSuccessful) { 
      output =  " - success. ID of the updated record: " + req_id;

   } else {

      var errorMessage = req_parent.getLastErrorMessage();
      output = " - failure. Could not update record: " + errorMessage ;

   }

  
} else {

    output = " - failure. Record not found.";
}

gs.log("##### For " + req_parent.number + output);