Cannot Fix Empty Labels in a table

[nysbigdave]

I have a table in two instances, my table consist of a few fields that have empty labels that i cannot fix, i manually added new labels and applied them to elements however , they dont take. the label exist in the labels dictionary however its not visible on the form

Any suggestions?

[alan_ta]

Ive experienced the same issue and attempted the following:

- Create new label via sys_documentation

- Import of the label from a different environment where label shows correctly via XML

All of these fail.

Workaround would be to recreate the column with similar details, copy all existing data over and get rid of the corrupted column

[robrien]

I think I've found a workaround for this:

If you see a missing label on a column in a table and entering the label clears the value on Save, then go to the Field Label (sys_documentation) table, and your record in the list.   You'll see the "missing" label and it's looks fine. The trick is to change the label in the Field Label record and save.   You can keep the new name or change it back to the original and save again.

[Shane J]

I tried this Rebecca and it didn't seem to help in my case.

I have seen this happen a few times now, usually on Task, where if I try to create more then a few fields at a time, the process times out and I only get a portion of what was supposed to be created.   And I almost always end up with one record that's like this.

[Shane J]

Not so much of a fix, as a workaround to prevent this from happening in the first place.

We recently upgraded to Eureka.   I started noticing this since then.   it appears to be caused by this   Transaction Quotas - ServiceNow Wiki .   There is quota rule called 'UI Transactions' that new field creation falls under.   By default it's set to 298 seconds - unless I only created one extra field (and no more), these transaction always took longer than 298 seconds.   In Dev, I inactivated this rule and have not been able to replicate the issue since, I just hit update and let it do it's thing until it's done.

[Lane Roberts]

Hi jued0001,

The issue you are describing is part of a known problem wherein the default UI transaction quota kills the transaction once the 298 seconds is reached. In part this is due to the fact that within Dublin and later version Table Flattening was introduced which increases performance on day to day operations, but because the Task table is now significantly larger, performing an online schema change on Task or Children of Task, now takes longer to complete. This results in the default Transactions Quota rules being breached on a fairly common basis, after upgrading to Dublin or Eureka+.

One workaround is to disable to the rule all together like you have on your DEV instance, however this will prevent the rule from stopping any long running action, which could potentially cause performance issues if left unattended. Another option is to add a condition to ignore sys_dictionary actions, which has worked for some customers to getting around the issue. For other customers simply increasing the timeout time for 15+ minutes has worked as well.

One thing to keep in mind however is that on long running onlineAlters where multiple new columns are being added to task, you will still hit the Apache Tomcat timeout which results in a blank white screen at approximately the 20 minute mark. This timer is unavoidable, and cannot be worked around, however your transaction will continue regardless of this particular timeout, and you will need to follow the transaction logs to know when the process completes.