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?

[puneetgoels1]

Sounds good. Please mark answer as correct, so that others with similar query can get help from this

[M Turner]

Just had this myself, Kingston, on cmdb_ci upon changing a field the label did not propagate correctly - although it seemed fine on one node but not the other even after cache clearing.

Went onto sys_documentation, found the record, confirmed the label was correct here even on the node that was not showing it correctly before. Exported the xml of the record for this one field and re-imported. The label fixed on the dictionary entry instantly.

[puneetgoels1]

From what I have understood instance one has correct fields but instance two has empty labels? If this is correct can you please do the following

1. open a new updateset

2. Modify the label of field in instance one and save

3. Modify the label of the field back to original name and save

4. Close the updateset and import it in instance 2

[andrewirwin]

This issue might be like my issue was, in which case the steps listed above may not work.. Let me explain why:

ServiceNow like any database based application / tool it has a max per save limit. Think of the bandwidth to the database as being a limited size highway, once you start pushing up to or attempt to go beyond that limit you will start having issue. The most agreed upon size for there MySQL databases is around 8126 KBs per database save. This does not mean that you are limited to only being able to save 8126 KBs to the database, what it means is that your total bandwidth size allowed at anyone time save is 8126. So you could save massive amounts of data to the database, however you only have a fixed limit for the bandwidth size going to the database. So if you exceed that limit your save will not be captured.

How does this relate to the initial problem of not being able to save a label correctly? Well believe it or not once you hit 8126 nothing is making it, so even that couple bytes in size for a label will not be saved. If you experience is like mine you will possibly see the label name on the field when you double click, otherwise it shows a blank.  

If you are not running a MSP / Domain Separated instance you might be able to have the Off Row Plugin turned on which will perform some trickery of where content is saved. However if your table is related to this Data Row size issue is on a Scoped app you likely can not use the Off row plugin because that plugin is limited to something like 21 character label size. So by the time you exclude your instance ID and the app scope name you don't likely have many characters left to spare. 

If you encounter this problem it can be fixed, but you better pack a lunch because its longing to be a long process.

So before I go further you might wonder why, or how did this happen? Well it all has to do with the size of the database file type your using. As an example if your using an HTML file your using a VCAR database file type, which just simply means it takes fare fewer of these big file types to eat up all of your available database bandwidth (per save). As a word of advice I would caution the use of HTML or Text strings over 4,000 characters. My customer had fallen in love with HTML editor fields, so once they reached 9 of these file types we ran into an issue. This problem likewise does NOT care about the form view, you might only have say 2 of these large fields on a view at anytime but still run into this issue. That is because when you save to the database it is literally allocating highway space for all of the fields on the table regardless if they are in the active view or not. 

So if your really interested in fixing this your going to need to first start off by creating a new table(s). You need to ensure you DO NOT have more than 6 of those big HTML / String (<4000) fields on your table(s). This might mean creating a couple new tables just to store your big fields. ServiceNow had initially suggested that extended tables would work just fine for this fix, however let me save you some time and head trauma, extended tables will not work for this...

Also be aware that this is not going to be a quick fix, it will take sometime.  I suggested packing a lunch, however I should clarify that is meant for after you have your  table fix ready and when you then plan to migrate this to production.  

I will keep this from turning into a novel, and highlight what we had to do to fix what could likely be the root cause of this missing label issue?

1. Create a full XML and XLSX export of your table. It is highly advisable that you export the data in the chunks or segments that you intended to piece it back together in the new table struce as. So if fields A & B are going to be moved to table 1, it will make it easier if you create an xml file for just field A and B to be used later.
2. Create your new tables
3. Remove enough of the big fields from the table that you free up space per save. This is where it gets tricky.
4. Add your new fields in your new table to your old table as a reference 
5. Dot walk the field(s) from your reference field to your form
6. Repeat this process until you get all of the fields added.
7. (What we did) Add the new tables temporarily to your related list
8. We then created a business rule that does an on before insert into our new tables (we had 3) from the original table
9. At this point you now need to create and run a fix script that will move your old data to its new home, however the challenge is that you don't have enough space get every field.  We had to spend a lot of time deciding which data would have to get reloaded manually after the fix. Looking back you should bring back the content you need to move to its new home first, then after it is moved and the old data deleted reload the data that is going to continue to reside in the old (original) table.
10. At this point you have basically created your own off row solution. 

In my example when we made it to the end we had 4 tables in the mix, and this was due to HTML fields being used. So from a users perspective now when they use the form it looks and works like any other form. If this was your issue, and you do proceed into this fun, try your hand at this 1st in a sub prod environment before you attempt this in production. If table you having issues with is not a high priority application it might be easier to rebuild the application, just make sure to spread the big field types among a few tables so as to not recreate the very problem you are trying to resolve. 

As of today I do not know of any other hotfixes or solutions available other than the Off Row plugin.

Lastly I'm not suggesting to anyone that the missing label issue couldn't be a few other issues, I'm just preparing you for worst case.

https://hi.service-now.com/kb_view.do?sysparm_article=KB0584932
https://community.servicenow.com/community?id=community_question&sys_id=c6838365dbd8dbc01dcaf3231f9619a3

[Sigval Bergesen]

Originally added a column first using another type then later changed it to true/false type. 

Then I could no longer see the field label. Turned out that the field lenght was sat to 4000.

changed it back to 32, now I can see the label.