Fields being truncated at 40 chars

gpopp
Kilo Expert

Hi!

I've created a table by importing a schema for it as a CSV file and using a transform map to add it to the sys_dictionary table. I did this because this table is being transferred from another database and has quite a few fields. Entering it by hand would be time consuming and error-prone.

An example of the entries in the csv file I used to create the table:

Table,Column name,Active,Type

u_widgets,Orders,true,String

u_widgets,Client Name,true,String

u_widgets,Thneed Count,true,String

etc.

The table created quite nicely. All strings created with the default 40 char size. There are roughly five fields that I needed to enlarge, so I modified by hand those fields' Max length to larger numbers such as 200.

Unfortunately, these fields are still quite locked at 40 chars. If I look at the form view for the table, the fields have large text entry boxes (apparently honoring the larger Max length) but when I try to add more than 40 chars, as soon as I save the entry it cuts off again back at 40.

Does anyone know what might be going on here? I've scanned the dictionary attributes for these fields and compared to more-than-40-char fields in other tables and I see no difference. Yet there must be a setting somewhere I've missed.

Any help would be vastly appreciated.

Thanks!

Greg

1 ACCEPTED SOLUTION

tony_barratt
ServiceNow Employee
ServiceNow Employee

Hi Gregory,



Try to change the max length to 256 first and then try to put it to a bigger value after.


It seems that if you don't put it to 256 first, the change will not occur at the database end (which you cannot change yourself).


As changing from 40 chars to say 400 requires a change to the field data type.


Introduction to Fields - ServiceNow Wiki



Best Regards



Tony


View solution in original post

20 REPLIES 20

Hi Pradeep,



I'm a newbie when it comes to ServiceNow. How do I "cache the instance"? I checked the knowledge base and the first thing I saw was that it affects performance. (Yikes!) I don't want to negatively impact my fellow developers.



Thanks,


Greg


Pradeep Sharma
ServiceNow Employee
ServiceNow Employee

Hi Greg,



Sorry for not updating this earlier. Here is the info.


  1. Ensure that a cache flush is not being run during business hours. Scheduled cache flushes, using cache.do, can affect overall performance and degrade system response times. Cache flushes are intended to prevent older data from interfering with changes and updates. Cache flushes should not be run during business hours and automatically triggered cache flushes are not recommended. Cache flushes are performed automatically when using update sets.

http://wiki.servicenow.com/index.php?title=Troubleshooting_Performance#Cache_Effects_on_Performance


Have you changed the string size in the table itself, or are you only changing the attribute on the field itself?table-string.jpg


Hi Joshua,



I navigated to : tables->u_widgets and edited the "Max Length" value of the field.


The form indicated "Dictionary Entry - field-name".


So - yes I do think I'm changing the size of the string in the table itself. Though, it certainly isn't behaving that way.



Thanks,


Greg


Once again (in an effort to be clear) the fields that are not behaving as expected were created "un-naturally" by applying an import set to the internal sys_dictionary (Dictionary Entry) table. If I add fields "by hand" (by clicking on insert a new row for instance), in the same table those fields obey the "Max Length" setting. I suspect that I need to add something else to another internal table to get these "auto-generated" fields to behave as they should.



I can, of course, work around this by deleting the ill-behaved fields and recreating them by hand (I've already done this for one of them) but I want to know what I'm missing using this method. I don't like mysteries.