I'm trying to run a script using sqlplus. My script is a simple delete statement. I execute it by putting the following in my ksh terminal:
sqlplus username/'password' #../sql/delete_societes.sql
../sql/delete_societes.sql is
DELETE FROM f2020.SOCIETES;
/
For some reason, it runs twice, causing the output "0 lines deteleted" to be printed twice and causing errors when I try to do an insert instead of a delete.
Make your script do either;
DELETE FROM f2020.SOCIETES
/
or
DELETE FROM f2020.SOCIETES;
without the slash.
From the documentation:
/(slash)
Executes the most recently executed SQL command or PL/SQL block which is stored in the SQL buffer.
and in the example further down:
Enter a slash (/) to re-execute the command in the buffer
... which is exactly what you are seeing.
Elsewhere in those docs:
The semicolon (;) means that this is the end of the command. Press Return or click Execute. SQL*Plus processes the command and displays the results
Like many clients SQL*Plus treats the semicolon at the end of your SQL statement as a statement separator - it is not part of the statement itself (which causes some confusion for e.g. dynamic SQL and JDBC calls) - and when it sees it it executes the command. The executed statement stays in the command buffer; and if you list to see the current command buffer, it will not show that semicolon. When you issue a slash it executes the buffer again.
Things are slightly different for PL/SQL; there the PL/SQL block has to be terminated with a semicolon, which is part of the block, and appears in the buffer. You have to use a slash to execute a PL/SQL block.
An example where you can see the sqlplus buffer content for SQL and PLSQL.
me#XEPDB1> help run
RUN
---
Lists and executes the most recently executed SQL command or
PL/SQL block which is stored in the SQL buffer. The buffer has
no command history list and does not record SQL*Plus commands.
R[UN]
me#XEPDB1> help /
/ (slash)
---------
Executes the most recently executed SQL command or PL/SQL block
which is stored in the SQL buffer. Use slash (/) at the command
prompt or line number prompt in SQL*Plus command line. The buffer
has no command history and does not record SQL*Plus commands.
/
me#XEPDB1> clear buffer [1/651]
buffer cleared
me#XEPDB1> l
SP2-0223: No lines in SQL buffer.
me#XEPDB1> select * from dual
2 /
D
-
X
me#XEPDB1> l
1* select * from dual
me#XEPDB1> select * from dual;
D
-
X
me#XEPDB1> l
1* select * from dual
me#XEPDB1> /
D
-
X
me#XEPDB1> r
1* select * from dual
D
-
X
me#XEPDB1> begin null; end;
2 /
PL/SQL procedure successfully completed.
me#XEPDB1> l
1* begin null; end;
me#XEPDB1> /
PL/SQL procedure successfully completed.
me#XEPDB1> r
1* begin null; end;
PL/SQL procedure successfully completed.
Related
I was trying to print "Hello World", but I continue to get number 7 returned. Also, after the 7 is returned, I cannot run another file without restarting cmd window. If I hit enter key, the number increments by 1. Please explain why this is happening and possible ways to correct.
Put a / on a new line at the end of the file to terminate the PL/SQL anonymous block.
SET SERVEROUTPUT ON;
DECLARE
name VARCHAR2(20);
BEGIN
name := 'Hello World';
DBMS_OUTPUT.PUT_LINE(name);
END;
/
SQL/Plus has read your file but has not found the statement terminator for the PL/SQL block so it is continuing to ask for more input to complete the statement. It is expecting a / character on a new line (the 7th line of the statement, the first being DECLARE as the SET command is a different statement) and when you press the enter key then it moves on to line 8 of the statement and is still expecting the terminator character so asks for more input (and repeats for the 9th, 10th and 11th lines).
You could press / then enter in SQL/Plus but it would be better to fix the file so it contains complete statements.
In the above code, I am giving schemaname as input and using that input it should connect to the database. But In this case the value i entered is not taken by the schemaname. This is how the out put and the error is:
declare schemaname varchar2(20);
exec :schemaname := XYZ;
BEGIN
end;
Error report -
ORA-06550: line 2, column 6:
PLS-00103: Encountered the symbol "" when expecting one of the following:
constant exception <an identifier>
<a double-quoted delimited-identifier> table long double ref
char time timestamp interval date binary national character
nchar
ORA-06550: line 4, column 1:
PLS-00103: Encountered the symbol "CONNECT" when expecting one of the following:
Could any one suggest how to make it work using spool
the code between declare and end is PL/SQL. Commands like CONNECT or SPOOL are SQL*Plus commands. You cannot use SQL*Plus commands in a PL/SQL block.
In your case you don't need PL/SQL at all:
Create a script with following content
connect &1
spool C:\ABC
#c:\ABC
spool off;
and run it
#your_script_name
BTW: there is no reason to run script c:\ABC while you are spooling into it. What exactly do you want to achieve?
exec[ute] is SQL*Plus and SQL Developer (and maybe other clients) shorthand for an anonymous block. It is a client command, it is not part of PL/SQL. You are trying to use it inside a PL/SQL declare section, where it is not valid or recognised.
If you want a client bind variable you need the var[iable] command:
var schemaname varchar2(20);
exec :schemaname := '&1';
BEGIN
...
Notice the single quotes around &1, as it's being assigned to a string variable.
But you can't connect inside a PL/SQL block either, and you can't use a bind variable for the connection.
connect :schemaname
will prompt for a password (even if you defined it's value as user/passwd) and try to connect as a user lieterally called :schemaname.
You can use a substituion variable, but you don't really need to define a new one; as you seem to be passing the credentials in, you can do:
connect &1
(without surrounding quotes)
I have created two batch files to run two separate .sql file in Windows Task Scheduler. The batch file for both looks like this:
sqlplus userid/password#database #C:\XXX.sql>>C:\output.log
echo commit; | userid/password#database
The first .sql file (SQL1) is a PL/SQL block like this:
SET SERVEROUT ON
DECLARE
....
BEGIN
IF ...
....
ELSE
#D:\DM_FIX.sql;
END IF
END
The DM_FIX.sql file is to insert a bunch of records into a table, and it starts with the INSERT command.
The second.sql file is not a block file. It's doing a bunch of DDL/DML comand. the file looks like below:
Truncate Table YYY
Reuse Storage;
Commit;
Insert into Table YYY
Select ... from
Commit;
Delete from Table YYY
where ...
Commit;
When I run the second .sql file, I get an output that indicates "The table has been truncated; #### records are inserted; #### records are deleted..."
But when I run the first, although the PL/SQL procedure is executed successfully, I don't get a line saying how many records are inserted, and I'm trying to figure out a way to do it.
Does any one know what could be the trick?
Thanks!
Revised Answer
As #Alex Poole helpfully pointed out, you can use the # nomenclature in a PL/SQL block from SQL*Plus, as that would load the second file's commands into the block that you're calling it from.
The reason that you're not getting any output is that, as far as SQL*Plus is concerned it's all one command: the SQLPlus block. In order to get output to your log for those commands, you'll need to create it yourself, using DBMS_OUTPUT. You would need to include a line like the one below after each command.
DBMS_OUTPUT.PUT_LINE(SQL%ROWCOUNT || ' rows inserted');
However, you should note that doing this will cause your script to throw errors if it's ever called from outside of a PL/SQL block. My original solution would avoid this restriction, as it eliminates the need to use DBMS_OUTPUT.
Original Answer
I find it difficult to believe that the PL/SQL in the first file is executing successfully. This is because you're mixing SQL*Plus commands with PL/SQL code. They are separate systems - it's like trying to use shell commands natively in a programming language. You should be getting PLS-00103: Encountered the symbol "#" when expecting... from the first file.
SQL*Plus doesn't have conditionals, so, in order to keep the PL/SQL and SQLPlus commands seperate, you'd need to fake it somewhat. I'd suggest putting the file name into a substitution variable, then using that to run a file:
VARIABLE v_my_file_bind varchar2(100)
DECLARE
...
BEGIN
IF ...
...
:v_my_file_bind := 'D:\EMPTY_FILE.sql';
ELSE
:v_my_file_bind := 'D:\DM_FIX.sql';
END IF;
END;
/
COLUMN v_my_file_column new_value my_file_substitution noprint
SELECT :v_my_file_bind v_my_file_column from dual;
#&&my_file_substitution
To show count of modified rows in PL/SQL, use SQL%ROWCOUNT:
begin
insert into my_table ...
select ...
from ...;
dbms_output.put_line('Rows inserted: ' || SQL%ROWCOUNT);
commit;
end;
/
Remember, that SQL%ROWCOUNT variable will reset to 0 after commit.
Documentation: http://docs.oracle.com/cd/B28359_01/appdev.111/b28370/sql_cursor.htm
I have a trivial question, I yet to understand the difference between dbms_output.put_line() and dbms_output.put()
set serveroutput on size 200000
Begin
dbms_output.put_line('A' || CHR(10) || 'B');
End;
/
exec dbms_output.put_line('A' || CHR(10) || 'B');
The above gives output A and B in two different lines. But
exec dbms_output.put('A')
exec dbms_output.put('B')
exec dbms_output.new_line
prints nothing. I am using SQL*Plus: Release 11.2.0.1.0 Production
You always have to write full lines in each PL/SQL block. Wehn you write
Begin
dbms_output.put_line('A' || CHR(10) || 'B');
End;
/
You write the two full lines "A" and "B" in one PL/SQL block. When you write
exec dbms_output.put_line('A' || CHR(10) || 'B');
the same holds true.
But when you write
exec dbms_output.put('A')
exec dbms_output.put('B')
exec dbms_output.new_line
you have three separate PL/SQL blocks. The first two write partial lines, which will be skipped by SqlPlus. The third block writes a full, but empty line.
If you write
begin
dbms_output.put('A');
dbms_output.put('B');
dbms_output.new_line;
end;
/
everything works as expected.
The reason for this is how console output in SqlPlus works: PL/SQL writes the output in an intermediate buffer. SqlPlus fetches the content of this buffer at the end of each executed PL/SQL block. It then prints that content to the console, while only printing full lines. Hence it skips the last line in the buffer, when it is not terminated by a new line character.
Technically I suspect SqlPlus to also print lines without a new line character, but starightaway overwrite them in the next step. Technically SqlPlus indeed fetches only full lines from the internal buffer, using the DBMS_OUTPUT.GET_LINES PL/SQL function.
Assuming you are on 11g, you should be considering PUT procedure since it is Obsolete and no longer supported by Oracle. In previous versions, with PUT, the line is not yet completed. Since it doesn't have end of line marker unlike PUT_LINE which automatically is followed by an end-of-line marker.
So, if you add an end-of-line marker, you will get the output.
You can have a look at this old question Is dbms_output.put() being buffered differently from dbms_output.put_line()?
I have some scripts that get run often, always from within a connected SQLPlus session.
I need a way to exit the script when an error occurs, without disconnecting or exiting SQLPlus itself. 100% of the time, when an error occurs, the connected DBA will need to issue one or more commands into the session. 100% of the time, when an error occurs, there are other SQLPlus statements (and thus must be outside of a BEGIN..END;) later on in the script that must not be executed or serious problems could arise.
NOTE: If you suggest WHENEVER SQLERROR EXIT then you didn't read the above text. That will disconnect and exit SQLPlus in addition to the script, which is not acceptable behavior.
I've found an interesting idea here which, when combined with spencer7593's answer, will get me selective sub-script calling, to which I can pass the PL/SQL output values. To wit:
VAR continue number;
EXEC :continue := 1;
BEGIN
SELECT some_bool_test() INTO :continue FROM dual;
END;
SET termout OFF
COLUMN script_name NEW_VALUE v_script_name
SELECT decode(:continue, 1, 'run_stuff.sql', 'skip.sql') script_name FROM dual;
SET termout ON
#&v_script_name :some_other_values
Where skip.sql is an empty text file.
UPDATE: I've moved most of this into a RUN.SQL file, where I pass in the boolean (0 or 1) as &1, the script name to call on success as &2, and then any other expected parameters to pass to the called script. Thus, it ends up looking something like this:
VAR continue number;
EXEC :continue := 1;
BEGIN
SELECT some_bool_test() INTO :continue FROM dual;
END;
#run.sql :continue 'run_stuff.sql' :some_other_values
It's not possible.
SQLPlus doesn't provide that level of control over the execution of a script.
Obviously, you'd need to AVOID using the WHENEVER SQLERROR EXIT ... command.
It's possible to gain conditional control over which SQL statements do or do not get executed as a result of raised exceptions (errors) using PL/SQL. But that doesn't address SQLPlus commands (which cannot be executed from within a PL/SQL block.)
DECLARE
lb_continue BOOLEAN;
BEGIN
lb_continue := TRUE;
BEGIN
sql statement
EXCEPTION
WHEN OTHERS THEN
lb_continue = FALSE;
END;
IF lb_continue THEN
BEGIN
sql statements
EXCEPTION
WHEN OTHERS THEN
lb_continue := FALSE;
END;
END;
Of course, that approach has it's own limitations and issues. Any DDL statements would need to be called dynamically; the easiest way to do that is an EXECUTE IMMEDIATE statement.
The biggest issue (in your case) is that it's not possible to execute SQLPlus commands from inside a PL/SQL block.
You can't exit the script and stay in SQL*Plus, but you can stop executing things. It isn't pretty, but assuming you can modify the script to add the control flow then you can just about do this with bind variable.
set serveroutput on
var flag char;
exec :flag := 'Y';
begin
if :flag != 'Y' then
raise program_error;
end if;
dbms_output.put_line('Doing some work');
/* Check for some error condition */
if 0 != 1 then
raise program_error;
end if;
/* Only reach this if earlier statements didn't fail
* but could wrap in another flag check if needed */
dbms_output.put_line('Doing some more work');
exception
when program_error then
dbms_output.put_line(sqlerrm);
:flag := 'N';
when others then
/* Real exception handling, obviously */
dbms_output.put_line(sqlerrm);
:flag := 'N';
end;
/
-- DML only does anything if flag stayed Y
select sysdate from dual
where :flag = 'Y';
-- Optional status message at the end of the script, for DBA info
set feedback off
set head off
select 'Something went wrong' from dual where :flag != 'Y';
set feedback on
set head on
When executed:
SQL> #script
PL/SQL procedure successfully completed.
Doing some work
ORA-06501: PL/SQL: program error
PL/SQL procedure successfully completed.
no rows selected
Something went wrong
SQL>
Any PL/SQL blocks in the script can check the flag status at the start, and raise program_error (just as a handy pre-defined exception) to jump back out. Anything that errors inside a PL/SQL block can update the bind variable flag, either directly or in an exception handler. And any non-PL/SQL DML can have an additional where clause to check the flag status, so if it's been set to N by the time that statement is reached, no work is done. (For an insert I guess that would mean not using the values form).
What this can't do is deal with any errors from plain SQL statements, but I'm not sure if that's an issue. If it is then those might need to be changed to dynamic SQL inside a PL/SQL block.
I know its old, but these two instructions at the very begining of the SQL script do the work:
WHENEVER SQLERROR EXIT FAILURE ROLLBACK
WHENEVER OSERROR EXIT FAILURE ROLLBACK