When I use isql with the same connect string and execute the same query in two different hosts, I get different result formatting -- one wraps each record after X characters, whereas the other host displays one line per record.
So I figured that I could use -w200 as an option when connecting isql in the connect string and the output is the same on both hosts. However, I would like to make both hosts output the same as there must be a default setting for the display width that takes effect if -w is not specified.
How is this setting specified?
According to the documentation, the default is supposed to be 80. If you are seeing different outputs on different hosts, it could be the way the host terminal is configured.
Related
We want to set this SET NUMFORMAT 99999999999999999.00 at the user/schema level, for all sessions. Currently ,when set this command , it is getting applicable for that session only. Can we do this globally , so that when ever we open the connection , this works >
SET NUMFORMAT is a SQL*Plus command. In general, it is a client-side setting to display the number.
You could always store the SQL*Plus settings in login.sql and glogin.sql. Whenever SQL*Plus starts up, it looks for a file named glogin.sql under the directory $ORACLE_HOME/sqlplus/admin. If such a file is found, it is read and the containing statements are executed. Additionally, after reading glogin.sql, sql*plus also looks for a file named login.sql in the directory from where SQL*Plus was and in the directory that the environment variable SQLPATH points to and reads it and executes it. Settings from the login.sql take precedence over settings from glogin.sql.
If you are just displaying the number, and want it to be displayed in desired format, then use TO_CHAR at individual SQL statement level.
For example,
SQL> select to_char(123.456,'999.9') VALUE from dual
2 /
VALUE
------
123.5
Bottomline, this is a SQL*Plus command, not an Oracle SQL or PL/SQL command. This will only affect how the data is displayed from SQL*Plus, not from other programs that access the database. There should be something similar in whatever you are using to display your data instead of SQL*Plus.
I'm totally new in running sql queries in linux and I'm having a hard time dealing with it's output.
So I managed to access my database in oracle in linux and trying to run a simple query right now:
SELECT IN_01, OUT_BD_01 FROM TRANSLATION_ROW WHERE IN_01 = 'LS3K5GB';
I'm expecting it to be in a table-like output but instead i got this:
Any Help would be much appreciated. By the way, I'm accessing my Oracle server through putty. I don't know if that helps in anything.
--forgot to mention that I also use sqlplus. Don't know if that would make any difference
Thanks in advance.
Welcome to the weird and wonderful world of Oracle.
Viewing large amounts of data (especially "wide" data) through sqlplus has always been less than pretty. Even back in the 1990s Oracle rival Ingres had a rather nice isql which made a much better fist of this, although the flipside of that was using isql to spool to a data file (no headers and trimmings, etc) was slightly harder. I think the rather primitive nature of SQLPLus is why TOAD/SQL*Developer etc have become popular.
To make the output easier to read, you need to learn the basics of sqlplus formatting, in particular SET LINES, PAGES, TRIMSPOOL, TAB, and the COLUMN formatting command.
Use COLUMN to control the formatting of each column.
One possible option is to use SET MARKUP and spool to a file, which formats the output as HTML table, but then you need a HTML viewer/browser to view the results.
On PuTTY your options are limited, but if you have xterm and can invoke the browser on Linux, you might find something like a shell script:
#!/bin/bash
sqlplus un/pw #the_file
firefox the_output.html
Contents of the_file.sql:
SET MARKUP ON
spool the_output.html
SELECT * FROM user_objects;
spool off
quit
If you have a share between the Linux system where the the_output.html resides and can mount that on WIndows, you could run the query on Linux with MARKUP oN, spool to the share, then click refresh on the Browser.
Clunky, and not really what you want, but try it and see what you get.
It displays the entire column that's it.
You can format your column before running the query with the below:
e.g.: format my column to display 10 characters only
column IN_01 format a10
There are some basic configuration tricks that you should apply when using SQLplus. A basic set of parameters would be something like this:
set pagesize 50000
set linesize 135
set long 50000
set trimspool on
set tab off
All these should be placed in a login.sql file which should be in the directory you are launching sqlplus from.
This will solve your current problem, but for further reading I suggest checking out this page: Configuring sqlplus.
Can someone point me to the relevant BOL info for this (odd to me) behavior?
I had to join the prod & staging copies of the same table (same db name, diff servers), for a quick query. So I simply needed a fully-qualified join.
This one errors:
SELECT top 10 *
FROM [172.26.196.105\Staging].[DbName].[dbo].[TableName]
This one works:
SELECT top 10 *
FROM [USCASQL01\STAGING].[DbName].[dbo].[TableName]
Edit: clarification ... obviously not a join, these selects were simply me assembling the fully qualified name of my staging db/table. This is not a linked server, but the one I'm connected to.
These, of course, refer to the same instance. I used the IP address\InstanceName since that is what displays in my Object Explorer, it returned an error - "Could not find server 'IP address\InstanceName' in sys.servers." True enough, sys.servers stores the computerName\InstanceName, which works.
Why would one work and not the other? IOW, Why can't it resolve the IP/Instance name in TSQL when it resolves it just fine in the Object Explorer? BTW, we frequently are storing IP's in sys.servers, this one just happened not to be.
Also, I recall from SQL Server7 (way back in the day), a utility that would allow you to create friendly-name aliases for ip's. Can't find it now, does it still exist?
TIA
This is because the first part of a four part qualified name is a reference to a linked server by name, not by an IP or network name. So, if you don't have the linked server set up, then you get the error you encountered.
For adding linked servers, you want to be looking at sp_addlinkedserver.
This is the BOL Page that describes how the four part names work.
I started using the system with a pre-made file called DB2.SQL. I am using this because it is what the tutorial said to use. I then edited this file and replaced the contents with my own code:
CREATE DATABASE BANKDB13 BUFFERPOOL BP0;
When I try to execute a SQL it though, I get this error:
DSNE377A INPUT DATA SET RECFM MUST BE F OR FB WTIH LRECL 80
What does this error mean and how do I correct it on the file?
I am running it with Vista TN3270 on Windows 7 over TSO, in SPUFI mode.
What I've tried so far:
When I start editing the file, I have a screen to change the defualts, and I have changed the RECORD FORMAT to F and FB as well as setting the RECORD LENGTH to 80 with no success.
EDIT:
I resolved the problem by deleting the DB2.SQL file and recreating it, and also making sure that the sizes I gave for the files were consistent with each other.
What SQL are you trying to execute on it?
The error means that the Record Format in the input data set must be either "F IXED" or "F IXED B" LOCK with a logical record length of 80.
So this is what the error means, how to correct it depends on the SQL you're running and the desired outcome.
What Tutorial is it that you refer to, do you have a link? Is this a real world problem, homework or you expanding your knowledge into mainframe DB2?
Your SQL snippet above is creating a DB, what is the INPUT DATASET file format that you are subsequently running SQL on?
When to use environment variable or command line parameter?
I think there are two ways to pass parameters to another process
in a script ,environment variable and command line parameters.
Thus,in which condition we choose one instead of another?
In most of the scripts I write, I allow both with the command line parameters taking preference.
This is to allow 'lazy' users who want to set'n'forget the parameters to do so.
It also allows over-riding of those parameters in special cases by the command line.
For those that don't want to take the chance that their parameters might be set up incorrectly, they can just use parameters.
Sometimes I'll even have more levels in the hierarchy, in order of precedence:
Value set while program running.
Command-line parameter.
Environment variable.
Local config file.
Global config file.
Default.
That way, for each variable, you just work your way up that list, setting it to the relevant value, if it's there.
I suggest you prefer command line parameters over environment vars unless
you need values that persist across commands.
you need system wide global values
Foredecker
Always prefer parameters when you can.
But say you have Script1 that calls Script2. Both scripts are distributed to many users. Script2 may need different parameters depending on the user, and the users don't want or are unable to alter Script1 for some reason. This is a case where environment variables might be useful.