When the SQL*Plus column headings line exceeds the PowerShell screen buffer size (in this case) by 4 or more, the window wraps the column heading line with the incorrect number of spaces.
This causes the column heading to not align with the values.
I get the same result regardless if set trim on or set trim off.
I get the same result regardless if set wrap on or set wrap off.
Is this a bug in PowerShell, Oracle InstantClient, or am I using SQL*Plus incorrectly?
Using Oracle 19c Enterprise Edition, Oracle InstantClient 19c 64-bit, Windows PowerShell Desktop 5.1.19041.1320, Microsoft Windows 10.0 build 19042.
PowerShell screen buffer size of 31. Column heading B is aligned with its data.
SQL> create table wrap (a varchar2(20), b varchar2(10));
Table created.
SQL> insert into wrap (a, b) values ('12345678901234567890', 'abcdefghij');
1 row created.
SQL> commit;
Commit complete.
SQL> set linesize 31
SQL> select * from wrap;
A B
-------------------- ----------
12345678901234567890 abcdefghij
PowerShell screen buffer size of 17. There are 16 spaces after column heading A and 0 spaces after column heading B. Column heading B is aligned with its data.
SQL> select * fro
m wrap;
A
B
-----------------
--- ----------
12345678901234567
890 abcdefghij
PowerShell screen buffer size of 16. There are 0 spaces after column heading A and 2 spaces after column heading B. Column heading B is not aligned with its data.
SQL> select * fr
om wrap;
A
B
----------------
---- ----------
1234567890123456
7890 abcdefghij
PS C:\> $PSVersionTable
Name Value
---- -----
PSVersion 5.1.19041.1320
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.19041.1320
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Thank you in advance.
Related
I selected every details customers tables in the Order Entry Schema but my data isn't ordered. How do i make the table presentable making every column and row clear to read and understand
I used the query select * from oe.customers and below is how my data was retrieved and makes it quite difficult to read.
CUSTOMER_ID CUST_FIRST_NAME CUST_LAST_NAME
----------- -------------------- --------------------
CUST_ADDRESS(STREET_ADDRESS, POSTAL_CODE, CITY, STATE_PROVINCE, COUNTRY_ID)
--------------------------------------------------------------------------------
PHONE_NUMBERS
--------------------------------------------------------------------------------
NLS NLS_TERRITORY CREDIT_LIMIT
--- ------------------------------ ------------
CUST_EMAIL ACCOUNT_MGR_ID
---------------------------------------- --------------
CUST_GEO_LOCATION(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_OR
--------------------------------------------------------------------------------
DATE_OF_B MARITAL_STATUS G INCOME_LEVEL
--------- -------------------- - --------------------
25-MAY-44 single F A: Below 30,000
CUSTOMER_ID CUST_FIRST_NAME CUST_LAST_NAME
----------- -------------------- --------------------
CUST_ADDRESS(STREET_ADDRESS, POSTAL_CODE, CITY, STATE_PROVINCE, COUNTRY_ID)
--------------------------------------------------------------------------------
PHONE_NUMBERS
--------------------------------------------------------------------------------
NLS NLS_TERRITORY CREDIT_LIMIT
--- ------------------------------ ------------
CUST_EMAIL ACCOUNT_MGR_ID
---------------------------------------- --------------
CUST_GEO_LOCATION(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_OR
--------------------------------------------------------------------------------
DATE_OF_B MARITAL_STATUS G INCOME_LEVEL
--------- -------------------- - --------------------
Image showing the problem
First off, if you're just running ad hoc queries, you probably don't want to be using SQL*Plus. You're almost certainly better off downloading SQL Developer which is an actual GUI that presents query output in a nice, GUI fashion.
SQL*Plus was designed back in a time when reporting generally meant generating fixed width output that would get spooled to a physical printer every morning and generate hundreds of pages of output on green bar paper that would get distributed to various humans in the company to review. So you need to think like an old school report developer.
First, you need to figure out how wide your output window is and set your linesize appropriately. If your output window is, say, 120 characters wide, you'd start with
set linesize 120
Now, you have to figure out how much space out of those 120 character that you want to give each column of your output knowing that larger string values will wrap within the column. So if you want to allow 15 characters for the customer first and last name
column cust_first_name format a15;
column cust_last_name format a15;
You'd need to do that for each column you're outputting. Realistically, it probably doesn't make sense to select a geographic location from SQL*Plus, you'd want to select components of that composite object.
I run the follows to update the record
update lims_min.languages
set Apriori = 'Русский'
where langid = 'RUS';
COMMIT;
when I do select, I see the ???? instead of the correct word. Apriori is NVARCHAR2.
Is there another trick here?
This is not an answer but is too long for a comment.
As already said you need to check NLS_LANG but also
your database character sets
what is the tool used to display data
the platform used (Windows, Linux, ...)
if you use Windows are you using a GUI program or a CLI program.
The following works on Linux CLI environment with SQLPlus:
SQL> select banner from v$version where rownum=1;
BANNER
--------------------------------------------------------------------------------
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
SQL> host echo $NLS_LANG
American_America.UTF8
SQL> --
SQL> select parameter, value
2 from nls_database_parameters
3 where parameter like '%SET%';
PARAMETER VALUE
------------------------------ --------------------
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_CHARACTERSET AL32UTF8
SQL> --
SQL> create table t(l varchar2(3), a nvarchar2(30));
Table created.
SQL> --
SQL> insert into t values('RUS', 'Русский');
1 row created.
SQL> --
SQL> select * from t;
L A
--------- ------------------------------
RUS Русский
SQL>
I'm using Toad 12.6 for Oracle and when I try to pull a field whose data type is Decimal(5,2), Toad truncates the decimal for any trailing 0 decimal digits at the end of a number.
For example:
expected -> toad actual
5.40 -> 5.4 *incorrect
1.34 -> 1.34 *correct
10.24 -> 10.24 *correct
30.07 -> 30.07 *correct
There are a lot of threads about Toad truncating/rounding data when numbers are too large, and that's solved by telling it not to show large numbers with scientific notation.
Is there a setting I haven't found yet which will force Toad to display these trailing digits up to the precision? I would appreciate not having to manually cast a number field (to_char() or to_number()) every time I want to display uniform results.
As far as I can tell, there's no such setting in TOAD.
If it were SQL*Plus, you'd use SET command, e.g.
SQL> set numformat 999G990D00
SQL> with test (col) as
2 (select 5.40 from dual union all
3 select 1.34 from dual
4 )
5 select col from test;
COL
-----------
5,40
1,34
SQL>
TOAD is not SQL*Plus. However, if you put (literally) this into TOAD's Editor window and press F5, you'll get a desired result in its Output tab:
set numformat 999G990D00
with test (col) as
(select 5.40 from dual union all
select 1.34 from dual
)
select col from test;
The result will be
COL
-----------
5,40
1,34
2 rows selected.
Just to emphasize:
press F5, not F9, Shift+F9, Ctrl+Enter - nope; press F5
result isn't displayed in the Data Grid tab (but the Output tab)
There's a good chance that you won't like that approach. In that case, I believe that TO_CHAR is your savior.
I have the following query.
insert into ORDER_INFO(ORDINF_PK,ORDINF_LGNDET_PK_FK,MEDIA_TYPE,ORDINF_MUSIC_FK,DAT)
values (1,1,'Music',21,TO_DATE('14-OCT-2015','DD-MON-YYYY'));
insert into ORDER_INFO(ORDINF_PK,ORDINF_LGNDET_PK_FK,MEDIA_TYPE,ORDINF_MUSIC_FK,ORDINF_SERIES_FK,DAT)
values (2,2,'Series',71,23,TO_DATE('07-NOV-2015','DD-MON-YYYY'));
however when I do:
select * from ORDER_INFO;
I get:
truncating (as requested) before column ORDINF_SERIES_FK
truncating (as requested) before column ORDINF_MOVIES_FK
ORDINF_PK ORDINF_LGNDET_PK_FK MEDIA_TYPE ORDINF_MUSIC_FK DAT
---------- ------------------- -------------------- --------------- ---------
1 1 Music 21 14-NOV-14
2 2 Series 71 07-NOV-15
I understand that it is truncating ORDINF_MOVIES_FK because there is no entry in that column, but why is it truncating the column ORDINF_SERIES_FK?
I managed to solve the issue, I did this.
set wrap on;
set pagesize 50000;
set linesize 120;
link here: http://www.anattatechnologies.com/q/2012/01/sqlplus-pagesize-and-linesize/
Pay attention - both rows inserted and ARE in the database, so INSERT succeeded.
The warning you get is a warning from SQLPlus program that means that column is display not with full width (maybe the definition of column is long and SQLPlus decides to show column shorter because data you have in there is short).
You do not need to worry about this in any case.
See this link for more explanation about SQL*Plus wrap.
I have problem with Oracle 10g database headig format.
I have this code
COLUMN id HEADING "Rodné|číslo" FORMAT A10
COLUMN name HEADING "Meno" FORMAT A20
COLUMN surname HEADING "Priezvisko" FORMAT A20
--some select here
Column id is char(10) type, other columns are varchar2(30) type. Result is this
Rodné
číslo Meno Priezvisko
---------- -------------------- --------------------
7951051548 Bohdana Filcova
4054207561 Bohumila Kmecova
As you can see header "Meno" interferes to first column and header "Priezvisko" interferes to second. I can't understand why. How can I solve this issue?
This seems to be a character set issue. SQL*Plus supports globalisation, so perhaps one of the characters you're using isn't in your session's characterset. If I set my NLS_LANG:
export NLS_LANG="ENGLISH_UNITED KINGDOM.WE8ISO8859P1"
Rodné
číslo Meno Priezvisko
---------- -------------------- --------------------
7951051548 Bohdana Filcova
4054207561 Bohumila Kmecova
... then I get the same behaviour you do. (It's slightly modified, but not fixed by set tab off). If I change my session to UTF8 then it aligns properly:
export NLS_LANG="ENGLISH_UNITED KINGDOM.UTF8"
Rodné
číslo Meno Priezvisko
---------- -------------------- --------------------
7951051548 Bohdana Filcova
4054207561 Bohumila Kmecova
This is in 11gR2, incidentally, so it isn't an Oracle 10g issue; my database character set is AL32UTF8. Also interesting is taking a dump of the value in each session, with 'select dump('Rodné|číslo', 1016) from dual'; with WE8ISO8859P1:
DUMP('RODNé|číSLO',1016)
--------------------------------------------------------------------------------
Typ=96 Len=20 CharacterSet=AL32UTF8: 52,6f,64,6e,c3,83,c2,a9,7c,c3,84,c2,8d,c3,8
3,c2,ad,73,6c,6f
... and with UTF8:
DUMP('RODNÉ|ČÍSLO',1016)
--------------------------------------------------------------------------------
Typ=96 Len=14 CharacterSet=AL32UTF8: 52,6f,64,6e,c3,a9,7c,c4,8d,c3,ad,73,6c,6f
Presumably with the former it thinks the output is taking up a bit more space than it actually is, so it isn't padding the heading quite right.
The č seems to be the problem. It is defined in Unicode, but not in WE8ISO8859P1 or WE8MSWIN1252 (sourced from here). In the Unicode version that's shown in the dump as c4,8d, and for the non-unicode it's building it from c3,84,c2,8d. Quite how and why that causes the effect you see is going beyond my understanding of character sets...