Creating new fields - Long transaction time

[Community Alums]

When creating new fields on a table that extends the task table, typically it only takes a few seconds to add a field.  For some reason, today, each new field is taking about 4 minutes and it runs a child process that seems to be making an update to over 1 million records on the task table.  I am following the same process I was just a few days ago when adding fields to the same form.  Is there something that has changed behind the scenes that I need to look at?

Any information is appreciated.

Edit: A similar thing has happened once before, when moving an update set to production for another team, About 1 million records on the task table were updated because of a field that was added.  It took a long time to complete.  This update set, and the fields today are the only two instances I've ever seen this behavior.

Thanks!

[Mark Roethof]

If you can reproduce this, I suggest you log a case on HI to have a ServiceNow engineer to also have look at it.

Kind regards,
Mark

---

LinkedIn
Community article list

[Community Alums]

So I just noticed something interesting.  I added a test field and changed the max value from 100 to 40 for this test, and it added as normal, just taking a few seconds.  I found this below information in the documentation, and if I'm reading it right, it should only have an affect when trying to save a record, but it certainly feels related.  Looking at the history of this table, it was indeed with exactly the 11th field of 100 or more max length that this behavior began taking place.  

Checking the update set from a couple months back...  There were definitely more than 11 fields already there, so it very well could be the same issue.

Hope this helps you too Mark.  Thanks for the response!

[Mark Roethof]

Well the 10 fields multiline (255+) is not really like it 🙂
You can easily have more, 14/15/16 is still oke. Also a lot of out-of-the-box tables have more then 10 multiline fields.

Though, it's a good advice. On a project earlier this year, I saw that folks had setup a new table of 150+ fields where 40+ of them where of multiline (255+). This did eventually even cause database corruption.

Kind regards,
Mark

---

LinkedIn
Community article list

[Community Alums]

I do agree that this is not likely the issue, but I did think it was worth pointing out that the doc references medium-length (100) or longer, rather than multiline (255+).  That is why I found it rather interesting that it was exactly the 11th field of length 100 that started the behavior.  I will try to replicate this on an OOB instance later and share the results.

[Community Alums]

I just created another one, with no default value, and the same behavior is taking place.