In SQL PLus, if I want to hide the command on screen, I use at the beginning of the script:
SET ECHO OFF
But what about this command? How to hide also this?
In MS-Dos you could use # in front of it, but in SQL*Plus?
EDIT:
I know the -S option for SQL*Plus, but the problem is that I am sending my script to the client and therefore I don't control how they are running SQL*Plus.
You might want to start SQL*Plus with the -S flag:
sqlplus -S user/password#db #path/to/your/script
The documentation says: SILENT Option
-S[ILENT]
Suppresses all SQL*Plus information and prompt messages, including the command prompt, the echoing of commands, and the banner normally displayed when you start SQL*Plus. If you omit username or password, SQL*Plus prompts for them, but the prompts are not visible! Use SILENT to invoke SQL*Plus within another program so that the use of SQL*Plus is invisible to the user.
SILENT is a useful mode for creating reports for the web using the SQLPLUS -MARKUP command inside a CGI script or operating system script. The SQL*Plus banner and prompts are suppressed and do not appear in reports created using the SILENT option.SILENT Option
So, with the silent option it seems that there won't be need to use set echo at all.
No, I know of no way to hide the 'set echo off' command itself, if echo is on.
However, echo is off by default. So, if echo is on when you initially start SQL*Plus, perhaps you have a login.sql or glogin.sql that contains 'set echo on'?
Check for glogin.sql in $ORACLE_HOME/sqlplus/admin, and for login.sql in the directory where you started SQL*Plus and any directory listed in $SQLPATH.
Hope that helps.
Related
I'm trying to run the following SQLPlus* set of commands:
/usr/tmp/> sqlplus -s / #my_test_script param1 param2 <<-EOF
SET ECHO OFF
SET HEADING OFF
SET VERIFY OFF
SET TERMOUT OFF
SET FEEDBACK OFF
SET PAGES 0
SET LINESIZE 400
EXIT
EOF
The SET commands are supposed to suppress the output from the script I'm running - but they have no effect, since the script itself probably has a different "scope" for ECHO, HEADING, etc.
The output is suppressed only once I move all those SET commands into the script-file itself.
Since this piece of code should eventually turn into a generic script for running other SQL scripts, putting those SET command inside every script is not a good solution.
Does anyone know of a way to force the SET command values over scripts ran within the same SQLPlus* "session"?
I agree with Shannon. You could try the following code (which changes the ordering a little bit):
/usr/tmp/> sqlplus -s / <<-EOF
SET ECHO OFF
SET HEADING OFF
SET VERIFY OFF
SET TERMOUT OFF
SET FEEDBACK OFF
SET PAGES 0
SET LINESIZE 400
#my_test_script param1 param2
EXIT
EOF
if I remember well, you could call from every script this initializing script using ## command. for example:
##init.sql
source
EDIT
also, from the oracle documentation :
SQL*Plus also supports a User Profile, executed after the Site Profile. This file is generally named login.sql. SQL*Plus searches for the user profile in your current directory, and then the directories you specify with the SQLPATH environment variable. SQL*Plus searches this colon-separated list of directories in the order they are listed.
You can add any SQL commands, PL/SQL blocks, or SQL*Plus commands to your user profile. When you start SQL*Plus, it automatically searches for your user profile and runs the commands it contains.
This is strange. New linux environment, accessed from my desktop via putty...
In my regular shell, I can up and down arrow to get command history. However, when I fire up BTEQ to talk to the database, I get this kind of gibberish in response to my up/down/ctrl+up/etc.
BTEQ -- Enter your SQL request or BTEQ command:
^[OA^[OB^[[A^[[B^[OA^[OA^[[D
Is this something in BTEQ? I would assume more of a setting in putty or "stty" type of command in my .profile. However, since the behavior is normal until I launch BTEQ I can't be sure.
BTEQ does not maintain a command history like the shell in your LINUX/UNIX environment. Therefore, using the up/down/ctl+up keys will be interpreted as input and not interpreted by the shell to navigate a command history.
Is there a way to echo/print the current connection string in sqlplus? I have a script that will be run in multiple databases, and I'd like a line at the top that looks like:
Currently executing test_script.SQL as USER1#MY_DB
It would be very convenient if there was a way to do this without having to change the file itself.
You can use the built-in SQL*Plus substitution variables _USER and _CONNECT_IDENTIFIER.
Add the following line to your SQL*Plus script:
prompt Currently executing test_script.SQL as &_USER#&_CONNECT_IDENTIFIER
Here is the link to the documentation.
See this question:
In SQL*Plus, how do I change the prompt to show the connected user and database?
Some scripts I have inherited will blindly call SET FEEDBACK OFF or SET ECHO OFF at the beginning of the script, then set them to ON or OFF at the end of the script. I would like to modify these scripts to determine what value was set before the script was run, and set the environment back to that value when the script completes.
How do I query SQL Plus environment values, store them, and restore them when a script has finished?
One method I have thought of:
SPOOL env-backup.sql
SHOW ECHO FEEDBACK TIMING
REM ...
#env-backup.sql
But
The values SHOW ECHO FEEDBACK TIMING spits out can't be executed directly (ECHO OFF vs SET ECHO OFF)
I would rather not create yet another file (or any modifications to the DB)
Not that it is necessarily related, but I'm using SqlPlus from Oracle XE (10g) on Windows
SQL*Plus has the STORE command just for this. It outputs a file which has all the environment settings. Executing the file would restore these settings. Type `HELP STORE' from the SQL*Plus prompt for more info.
You might be interested in those scripts
If you want each SQL to be run independently you could call them using the HOST command. That is, for misbehaving scripts call HOST SQLPLUS username/password#tnsname #script.sql and it will run in a new process.
Why not just put the desired values for your connection in the glogin.sql script provided?
It's normally found in %ORACLE_HOME%\sqlplus\admin
From my glogin.sql:
--
-- Copyright (c) 1988, 2005, Oracle. All Rights Reserved.
--
-- NAME
-- glogin.sql
--
-- DESCRIPTION
-- SQL*Plus global login "site profile" file
--
-- Add any SQL*Plus commands here that are to be executed when a
-- user starts SQL*Plus, or uses the SQL*Plus CONNECT command.
--
-- USAGE
-- This script is automatically run
--
set pagesize 60
set linesize 500
set wrap off
Then just reconnnect after running any scripts that alter your environment (or run #glogin.sql itself).
I have the following batch script:
sqlplus ms/ms#orcl < drop.sql
sqlplus ms/ms#orcl < create.1.0.sql
This works fine when I double click on the bat file in Windows Explorer and run it.
But when I type the command name from the DOS prompt I get an error:
C:\>create.bat
C:\>sqlplus ms/ms#orcl 0<drop.sql
The handle is invalid.
C:\>sqlplus ms/ms#orcl 0<create.1.0.sql
The handle is invalid
Any ideas?
Update: Made the change to use # instead of <. This gets around the error but now the script only executes the first file and then leaves you at the SQL> prompt. To get the second file to execute you have to type exit at the prompt, then the second file runs. Not sure how to get both files to execute. ??
If you want SQL*PLUS to execute a script, a better way than command-line redirection is the # syntax:
sqlplus ms/ms#orcl #drop.sql
sqlplus ms/ms#orcl #create.1.0.sql
Also read up on the ## syntax, which you can use to execute a .sql script from another .sql script in the same directory.
SQL> help #
SQL> help ##
Made the change to use # instead of <.
This gets around the error but now the
script only executes the first file
and then leaves you at the SQL>
prompt. To get the second file to
execute you have to type exit at the
prompt, then the second file runs. Not
sure how to get both files to execute.
??
I ended up writing a python script to run sql plus and then exit it to get around this issue. I have yet to find any way around that limitation. Although you would only have to deal with the issue once if you use ## as was suggested. You would just have to run the second script from the first script.