I am writing a script where the output from one procedure is needed for multiple later procedures. So, I need bind variables, not substitution variables. But, whenever the variable is used, it is cleared. That makes it impossible to use a variable's value more than once. The exact same script works in SQL*Plus. I have made a shortened script below that demonstrates the problem.
Is this a setting that can be changed in SQL Developer? Is this a bug? In my case, I am using SQL Developer version 4.1.5.21.78.
var x varchar2(1)
var y varchar2(1)
print x
print y
exec :x := 'Z';
exec :y := 'Z';
print x
print y
exec :x := :y;
-- Why did that last line clear y?
print x
print y
output
X
------
Y
------
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
X
-
Z
Y
-
Z
PL/SQL procedure successfully completed.
Y
-
X
-
Z
This seems to be a bug in 4.1.5, and possibly other versions, that has been fixed by version 4.2.0.17.
exec is just a wrapper for an anonymous block, but using an explicit block instead also shows the problem:
begin
:x := :y;
end;
/
I'm pretty sure I've seen this reported before, but the only example I can find is this question; as that notes you can work around it by reassigning the value to itself:
begin
:x := :y;
:y := :y;
end;
/
or slightly less readably:
exec :x := :y; :y := :y;
It certainly appears to be a bug, but as it's fixed in the current release, upgrading seems like a sensible way to resolve it. Otherwise you'd need to raise a service request to Oracle - though I suspect they'd advise to upgrade anyway.
(I may have been thinking all the way back to this, but that seems to be a different problem as that example looks OK in 4.1.5. I can't see any bug reports in My Oracle Support, for either issues; but they aren't always published.)
Related
I use Oracle database version 19.3.0 and it can handle parameter names longer than 30 chars. If I execute in Delphi FireDAC-procedure "ExecProc" to call Stored Procedure in SQL, Delphi throws "ORA-01036 : illegal Variable name/number" exception and calling of the procedure terminates prematurely, because one parameter name is longer then 30 chars.
Is there some FireDAC property to change this behavior without changing parameters name length?
"C:\Program Files (x86)\Embarcadero\Studio\19.0\source\data\firedac\FireDAC.Phys.Oracle.pas"
Solution: Change pbByName to pbByNumber
procedure TForm5.Button1Click(Sender: TObject); begin
FDStoredProc1.ParamBindMode := pbByNumber;
FDStoredProc1.FetchOptions.Items := [fiBlobs, fiDetails]; //This disables automatic fetching of parameters from server
FDStoredProc1.Params.CreateParam(ftString,'Averylongparamternamethathopefullyislongerthanthirtycharacters',ptInput);
FDStoredProc1.params.CreateParam(ftString,'outparam',ptOutput);
FDStoredProc1.Params[0].AsString := 'Hello World';
FDStoredProc1.ExecProc;
ShowMessage(FDStoredProc1.Params[1].AsString);
end;
I have a pl/SQL query that has a variable .
I want DBMS_OUTPUT.PUT_LINE to a file used on the machine (linux)
Does someone know how to do this?
You need to put some pieces together. Here is my inspiration: DBMS_OUTPUT.PUT_LINE not printing
a) put your plsql in an sql script, e.g. d.sql - the key here is set serveroutput:
set serveroutput on size 30000;
begin
DBMS_OUTPUT.PUT_LINE('my line');
end;
/
exit
b) Then write another script - ksh this time - containing:
sqlplus / #d.sql > output.txt
If you want to restrain what displays from sqlplus, then read appropriate documentation about set statement
I have created a Stored Procedure in Oracle (Via TOAD).
I need to deliver this procedure to some other developers. All is need to do is Wrap the procedure so that at basic level he/she should not be able to view the code.
At the same time, the developer should be able to create the procedure and execute/test it.
my procedure is saved in say FileName.sql whose content are like:
Create or Replace Procedure
IS
Declaration
Begin
Code
End;
Now i want this FileName.sql to be wrapped. So that the encrypted file can be send to other to check in different environment.
Please help me in how to wrap, and then how the other guy will be able to create the procedure, and execute the same.
Thanks in advance.
The Oracle WRAP utility does exactly that - allows you to encode a stored procedure in a form suitable for shipping.
The wrapped code is as portable as source code, but cannot be examined as plain text.
You will need access to the command line using a suitable system user (i.e. one that has access to the Oracle binary commands e.g. sqlplus etc.) and the basic syntax is:
wrap iname=input_file [ oname=output_file ]
If you do not specify any extensions, the default for input is .sql and output is .plb
Once you have generated a .plb file, you can execute it against the database to create your stored procedure.
See:
http://docs.oracle.com/cd/B28359_01/appdev.111/b28370/wrap.htm#LNPLS016
http://docs.oracle.com/cd/B10500_01/appdev.920/a96624/c_wrap.htm
WARNING
WRAPencoded procedures are not completely secure - it is possible to "unwrap" them.
A better way of using WRAP is to put the procedure(s) you wish to protect in a package and WRAP the package definition.
Let's say your procedure is:
CREATE OR REPLACE PROCEDURE PR_OUTPUT_TEXT(
P_TYPE IN CHAR,
P_TEXT IN VARCHAR2
) IS
V_TYPE CHAR(3) := UPPER(P_TYPE);
BEGIN
IF V_TYPE = 'LOG' THEN
APPS.FND_FILE.PUT_LINE(APPS.FND_FILE.LOG, TO_CHAR(SYSDATE,'HH24:MI:SS')||' - '||P_TEXT);
ELSE
APPS.FND_FILE.PUT_LINE(APPS.FND_FILE.OUTPUT, P_TEXT);
END IF;
END PR_OUTPUT_TEXT;
you would normally call it using:
EXECUTE PR_OUTPUT_TEXT('LOG', 'Kittehz!!!')
In a package you would define the package body and the procedure thus:
CREATE OR REPLACE PACKAGE BODY USER.MYPACKAGE AS
PROCEDURE PR_OUTPUT_TEXT(
P_TYPE IN CHAR,
P_TEXT IN VARCHAR2
) IS
BEGIN
IF V_TYPE = 'LOG' THEN
APPS.FND_FILE.PUT_LINE(APPS.FND_FILE.LOG, TO_CHAR(SYSDATE,'HH24:MI:SS')||' - '||P_TEXT);
ELSE
APPS.FND_FILE.PUT_LINE(APPS.FND_FILE.OUTPUT, P_TEXT);
END IF;
END PR_OUTPUT_TEXT;
END MYPACKAGE;
and you would call the package using:
EXECUTE USER.MYPACKAGE.PR_OUTPUT_TEXT('LOG', 'ERMAHGERD KERTERNS!!!')
From documentation, to be precise, this is what you need to do :
Running the wrap Utility
For example, assume that the wrap_test.sql file contains the following:
CREATE PROCEDURE wraptest IS
TYPE emp_tab IS TABLE OF employees%ROWTYPE INDEX BY PLS_INTEGER;
all_emps emp_tab;
BEGIN
SELECT * BULK COLLECT INTO all_emps FROM employees;
FOR i IN 1..10 LOOP
DBMS_OUTPUT.PUT_LINE('Emp Id: ' || all_emps(i).employee_id);
END LOOP;
END;
/
To wrap the file, run the following from the operating system prompt:
wrap iname=wrap_test.sql
The output of the wrap utility is similar to the following:
PL/SQL Wrapper: Release 10.2.0.0.0 on Tue Apr 26 16:47:39 2005
Copyright (c) 1993, 2005, Oracle. All rights reserved.
Processing wrap_test.sql to wrap_test.plb
If you view the contents of the wrap_test.plb text file, the first line is CREATE PROCEDURE wraptest wrapped and the rest of the file contents is hidden.
You can run wrap_test.plb in SQL*Plus to execute the SQL statements in the file:
SQL> #wrap_test.plb
After the wrap_test.plb is run, you can execute the procedure that was created:
SQL> CALL wraptest();
More information in docs
DECLARE
V_NUMBER NUMBER :=23;
BEGIN
LOOP
V_NUMBER:=V_NUMBER+1;
EXIT WHEN V_NUMBER:=25;
--Some kind of function to be applied for printing and nesting lines into CSV or TEXT file.
END LOOP;
COMMIT;
END;
Scripting an Oracle SQL Query for Creating a CSV or Text Typed File Output
Consider running this from a SQL Plus session and use the SPOOL command. All output of the SQL command that follows will be written to the file name you specify.
If you need to append your results each successive time the SQL commands are run, then an OS level command would work appropriately when invoking this sqlplus executable block of PL/SQL:
Where the file name of this script is: "sample_csv_out.sql"
DECLARE
v_total_columns constant number:= 3; -- Number of columns queried
v_column_counter number;
v_csv_record varchar2(1000);
c_csv_column_format constant varchar2(15):=
'<<COLUMN1_VAL>>,<<COLUMN2_VAL>>,<<COLUMN3_VAL>>';
cursor result_cur is
SELECT column1, column2, column3
FROM tablea
WHERE column1 = ... ;
BEGIN
v_csv_record:= 'COLUMN1,COLUMN2,COLUMN3';
dbms_output.put_line (v_csv_record);
FOR i in result_cur LOOP
v_csv_record:= replace(c_csv_column_format, '<<COLUMN1_VAL>>', i.column1);
v_csv_record:= replace(v_csv_record, '<<COLUMN2_VAL>>', i.column2);
v_csv_record:= replace(c_csv_record, '<<COLUMN3_VAL>>', i.column3);
dbms_output.put_line(v_csv_record);
END LOOP;
END;
So, for example in a WINDOWS O/S environment, the call to append the output to a specific file name would be:
C:\> sqlplus sample_csv_out.sql >> mycsv_out.csv
The >> notation instructs the operating system to pipe the output of running sample_csv_out.sql via a sqlplus session.
The command DBMS_OUTPUT does the rest. If you need more details, see more Oracle documentation on DBMS_OUTPUT.
COMMENTS: I chose the RECORD STRING TEMPLATE approach to make this script a little more flexible and reusable. I recommend to keep any data manipulation logic within the CURSOR statement. Often when the two are mixed, it gets harder to debug any typos in syntax within a long string of values.
The construction of an output record was also designed to reduce typos, mistakes and frustration... if there are more than 3 columns in your own scripts, adding another element to the output string is mostly a cut-and-paste operation. Likewise with the "header" row (column titles).
You can read and write files in PL/SQL using the UTIL_FILE package
http://docs.oracle.com/cd/B19306_01/appdev.102/b14258/u_file.htm
I've got a PL/SQL-Block which looks like this:
declare
L_Count number := 10;
begin
if L_Count > 0then
dbms_output.put_line('l_Count > 0');
else
dbms_output.put_line('l_Count <= 0');
end if;
exception
when others then
dbms_output.put_line('exception occurred');
end;
Note the fourth line containing 0then instead of 0 then.
Using PL/SQL-Developer, I can execute this block as an SQL statement, which actually outputs l_Count > 0. Using a "Program Window" and compiling this, PL/SQL-Developer says the following error:
Unable to perform operation due to errors in source code
How can this statement execute but not compile?
Thank you for your hints!
The behavior is not what I would expect either. However, both the PL/SQL Developer SQL Window and Command Window modes execute this consistently with how SQL*Plus behaves. So, this is either:
Not a bug, or
An Oracle bug but not an Allround Automations bug.
Execution and compilation are two separate things. The code block is an anonynous block and it cannot be compiled. However you can execute the block. Execution would show you l_Count > 0.
Thanks,
Aditya