One last thing: If indeed the "problem" database has a different character set, then matching character sets in your client prior to that connection should also work as a solution. That is not always convenient in a script set though. It is possible that the "problem" database being a different character set is masking extra overhead all the time and if setting the client NLS parms to match the database it will be connecting to is not too much trouble in the context of your applications, that is generally a better solution. This of course won't magically allow you to store multibyte character sets in single bytes, but it will avoid the conversion overhead when you're really only using ASCII anyway. mwf From: Dennis Williams [mailto:oracledba.williams@xxxxxxxxx] Sent: Monday, July 18, 2011 10:36 AM To: Mark W. Farnham Cc: Mark.Bobak@xxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx Subject: Re: Column width different in view Thanks everyone. Wow, I never would have guessed this one. Amazing resources on this list. <snip> From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Bobak, Mark Sent: Friday, July 15, 2011 6:09 PM To: Dennis Williams; oracle-l@xxxxxxxxxxxxx Subject: Re: Column width different in view What is nls length semantics set to? What is character set? <snip> List, We have a situation where a view is created on a table. The underlying column is defined as CHAR(18). We are doing this to a number of Oracle 10.2.0.4 databases. On all of them the view creates just fine. But on one database the column in the view is created as CHAR(54). Has anyone encountered anything like this? Thank you, Dennis Williams