This content has been marked as final. Show 6 replies
I cannot reproduce this:
SQL*Plus: Release 220.127.116.11.0 Production on Fri Feb 3 10:34:38 2012
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Oracle Database 11g Enterprise Edition Release 18.104.22.168.0 - Production
With the Partitioning option
SQL> select rpad('Hello World', 5) Hdr from dual;
If you don't have the latest patchlevel installed , it may be a bug in an earlier version.
Edited by: oradba on 03.02.2012 10:44
Dunno. Is there something odd in a glogin.sql or login.sql initialization file?
1) Why is sqlplus behaving differently in R2?
Is it worth the effort to install a R1 client on a PC to check R1behavior?
OK, I tried without using any login.sql file: no joy. Next, I managed to establish a connection from an 11.1 sqlplus client to my 11.2 instance: it did not exhibit the anomaly.
Since we are running 22.214.171.124.0, I will try patching to the latest release and see if that fixes things.
I installed 126.96.36.199.0 and the problem still exists.
I'm not sure what to try next. Maybe I can write a simple OCI program that prints out what Oracle thinks the column widths coming back from the server are. If the widths are good, that would indicate a bug in sqlplus.
Any other suggestions? A colleague says we should install an 11gR1 client on our development server and use that for running sqlplus, but that's not how we'll be deploying and we'd like to be able to use our existing code as-is in production.
we are experiencing exactly the same problem (in our case 100s of sqlplus scripts utilising substr) - and this is the first mention I've found of the problem, so will be very interested in any solution
Edited by: user7382048 on 13-Feb-2012 07:49
I also just ran into this problem, and it is quite annoying.
This might help with the problem: Note 330717.1 Output widths change after upgrade.
It seems that you might have upgraded to the AL32UTF8 character set from an 8-bit character set. Check your NLS_CHARACTERSET setting:
select * from SYS.NLS_DATABASE_PARAMETERS where parameter = 'NLS_CHARACTERSET';
But this doesn't answer the burning question - Is there a way to force column widths to be handled the way they used to be (without needing to explicitly define a format for each column)?