I personally wouldn’t risk making this change unless absolutely necessary - while you may be able to extend the length of the fields, depending on how IFS uses that field it could cause serious impacts in basic functionality.

If you do need to, you’ll have to very carefully test all areas use that/those field including reports etc to ensure the system doesn’t start generating bad data without it being immediately obvious (e.g. it might concatenate fields and end up truncating part of the longer data without generating any error)

Nick

Thanks Nick.  I might see if I can do this in a Race environment and test what the outcome is. 

I’d be interested to know the outcome or any issues you encounter; please add a follow up once you’ve tested it.  Thanks!

For sure.  I’ll keep this thread updated.

This change moves the storage of the larger strings out-of-line from the other columns in the record, much like they do with LOBs. That will cause extra logical reads for the bigger records.

http://www.dba-oracle.com/t_max_string_size.htm

“WARNING:  You MUST run utl32k.sql immediately after changing max_string_size=extended, else you risk invalidating the database columns.”

This parameter is specifically not supported by IFS as is mentioned in the Foundation1 Documentation under “IFS Development Guide > Core Server > Base Server Development > Localization and Internationalization > Database Character Set”:

Note: Storing VARCHAR2 of size 32767 in the database by setting the MAX_STRING_SIZE to Extended is not supported.