glide_list not saving multiple entries

[SharpAl]

We updated the configuration item column in the change table (dev instance) to be a glide_list entry. Everything seems fine with it, you can add a list of items using the select box and upon closing ("locking") the field again the entries all seem to be there.

As soon sd you hit save and the page reloads the 2nd, 3rd.. etc entries all get wiped. The first item selected is the only one that ever gets saved. I've had a bit of a look around and compared against other glide_list fields but I can't see anything wrong.

Any ideas?? Cheers.

[Mark Stanger]

My guess is that it's probably the Max length attribute on the dictionary that's causing the problem. A reference field has a Max length of 32 (which is exactly enough to store the sys_id of a single record). A glide_list needs a larger length so that it can store multiple sys_id values. I think the other glide_list fields have a max_length of 4000 to accommodate more values. Check the Max length on the 'watch_list' field on the task table to be sure.

[SharpAl]

Thanks for the quick reply. My apologies though, I should have stated that I checked this and, whilst it was at 32, changing it to 4,000 didn't change the behaviour.

[Mark Stanger]

I just tested this on /demo with the same result. The problem is with the data types at the database level. Once you have a created field, you can change the field type as long as the data type underneath is the same. In this case, the data types aren't the same so it won't work. You'll have to create a new list field instead of changing the existing reference field.

[CapaJC]

Not sure it'll work, but you might try changing the max_length to 254. You may need to deactivate the business rule that prevents reducing the max_length size if you've already changed it to 4000. The business rule is "Dictionary Change Rationally". I think a length of 254 would still preserve the initial data type in the database (VARCHAR, iirc). Anything larger, and you run into what Mark described.