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;
Related
I am working with Delphi 7 and Firebird 2.0. In my application I am using TIBScript components. The problem arises when I use local variables in the script. Firebird requires the names of local variables to be preceded by a colon in some cases. That’s where the problem lies in. The application stops showing the error message:
Dynamic SQL Error
SQL error code = -104
Token unknown - line 4, column 66
?
The token in question is the colon. Here is how my script looks like:
SET TERM ^ ;
EXECUTE BLOCK AS
DECLARE test_variable INT;
BEGIN
SELECT tt.id FROM test_table tt WHERE tt.name LIKE 'abc%' INTO :test_variable;
INSERT INTO test_table2(id, test_column)
VALUES(1, :test_variable);
INSERT INTO test_table3(id, test_column)
VALUES(1, :test_variable);
...
END^
SET TERM ; ^
The same script executes without any errors when run from IBExpert.
How can I use local variables in a TIBScript? Any help would be appreciated!
I want to add that this problem occurs only with variables inside an EXECUTE BLOCK construct. There is no problem with local variables in stored procedure and trigger definitions.
After executing the method TIBSQL.PreprocessSQL (Unit IBX.IBSQL line 2362), parameters marked with ":" on the front are replaced by "?". So you should use parameters without ":". Also I think it should be removed SET TERM. Instead, to set terminator value use the IBScript.Terminator property.
P.S. I watched unit IBX.IBSQL in Delphi 10.3 Rio.
this
EXECUTE BLOCK AS
DECLARE test_variable INT;
BEGIN
SELECT tt.id FROM USERS tt WHERE (tt.fname LIKE 'abc%') INTO test_variable;
END;
is executed properly when
IBScript.Terminator = ^;
Edit:
You can't execute INSERT with parameters in EXECUTE BLOCK using TIBScript component.
As Mark Rotteveel comented:
Unfortunately removing the colon is only an option in the into clause
in not with other occurrences of local variables or parameters.
I need to get input from user in runtime in ORACLE. I am trying to do this.
Get input 'name' from user
Greet user with 'name' using DBMS_OUTPUT
My code so far:
ACCEPT name PROMPT 'Your name:'
declare
a varchar2(10);
begin
a := '&x';
end;
You need to use the name you assigned in the ACCEPT statement in your code. So
ACCEPT name PROMPT 'Your name:'
begin
dbms_output.put_line ('Hello &name !');
end;
/
Regarding your comment:
"ACCEPT name PROMPT 'Your name:' still is a unsuported command"
According to your comment you're using Oracle's LiveSQL, right? Well, accept is a SQL*Plus command for handling input parameters; SQL*Plus is part of a client install. LiveSQL is a different client. If you read its FAQs you will see:
Can I use input parameters?
No, we do not support input parameters at runtime.
HI everyone I wrote a kind of a simple procedure in Aginity(Netezza). The stored procedure basically has to load data from one db.table1 to db2.table2. Simple right? Then then the procedure - procedure 1 takes in an argument, which is the name of the database(db).
This is the error message I get whenever I try to run my procedure:
/*
ERROR [HY000] ERROR: syntax error, unexpected VARIABLE, expecting BEGIN at or near "db_arg"
*/
The procedure looks like something like this:
CREATE OR REPLACE PROCEDURE LOAD_data_proc(CHARACTER VARYING(15))
RETURNS INTEGER
LANGUAGE NZPLSQL AS
BEGIN_PROC
DECLARE
db_arg CHARACTER VARYING(15);
/* if I remove above declaration I get the following error message: ERROR [HY000] ERROR: ResolveCatalog: error retrieving database 'STG_DB_NAME' */
db_arg ALIAS FOR $1;
/* and bunch of other arguments and declarations */
BEGIN
/* logic here if then else statements */
END;
END_PROC;
Did anyone encounter this problem before?
It's not 100% clear from your description what the actual NZPLSQL code is, but I can reproduce your first error using:
CREATE OR REPLACE PROCEDURE LOAD_DATA_PROC(CHARACTER VARYING(15))
RETURNS INTEGER
LANGUAGE NZPLSQL AS
BEGIN_PROC
DECLARE
db_arg CHARACTER VARYING(15);
db_arg alias for $1;
BEGIN
db_arg := 'SYSTEM';
RAISE NOTICE '%', db_arg;
RETURN 0;
END;
END_PROC;
Note there is a double declaration of the same variable name in the DECLARE block. This is not allowed, and this causes:
ERROR [HY000] ERROR: syntax error, unexpected VARIABLE, expecting BEGIN at or near "db_arg"
Removing one of the declarations will allow the procedure to complete.
IBM docs on NZPLSQL regarding parameter passing to stored procedures is available here: https://www.ibm.com/support/knowledgecenter/SSULQD_7.2.0/com.ibm.nz.sproc.doc/c_sproc_parameter_passing.html
and here:
https://www.ibm.com/support/knowledgecenter/SSULQD_7.2.0/com.ibm.nz.sproc.doc/c_sproc_arg_list.html
As for:
ERROR [HY000] ERROR: ResolveCatalog: error retrieving database 'STG_DB_NAME'
This occurs when I attempt to call a non-existent stored procedure, in a non-existent schema of a non-existent database such as:
CREATE OR REPLACE PROCEDURE LOAD_DATA_PROC(CHARACTER VARYING(15))
RETURNS INTEGER
LANGUAGE NZPLSQL AS
BEGIN_PROC
DECLARE
db_arg alias for $1;
BEGIN
CALL UNKNOWNDB.UNKNOWN_SCHEMA.UNKNOWN_STORED_PROC(1234,5678,7890,123456,1234567);
END;
END_PROC;
which gives me:
ERROR [HY000] ERROR: ResolveCatalog: error retrieving database 'UNKNOWNDB'
Hopefully this helps to explain the errors and how to avoid them.
ok I figured it out... you can pass db_names as arguments to the netezza stored procedure but every time you use the argument inside the procedure, you have to use a dynamic query...
Hope this helps somebody, someday.
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