I am getting following error when calling a oracle plsql procedure using spring jdbc in java.
org.springframework.jdbc.BadSqlGrammarException: CallableStatementCallback; bad SQL grammar [{call "Procedure name"; nested exception is java.sql.SQLException: ORA-06550: line 1, column 7:
PLS-00306: wrong number or types of arguments in call to 'procedure_name'
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
This procedure exist under a package A in schema S1. I have created a synonym in schema S2 for this package A and trying to execute this procedure using spring SimpleJdbcCall, with schema name S2 but it's giving me the above error.
But when i execute this query using SqlPlus in schema S2, this procedure executes fine, it means there is no grant issue with this.
When i execute the same procedure with the Schema name where it actually exists (S1) then also it executes fine using spring-java.
Is there any issue related to synonym created in Schema S2 for this package A??
Am i missing anything here?
I hit the same issue and like you explicitly declared the parameters. The fix was to additionally specify:
new SimpleJdbcCall(dataSource)
.withoutProcedureColumnMetaDataAccess()
...
My assumption is that the synonym is preventing the parameter inference from working without actually stopping it happening and as a result the driver concludes that the stored procedure does not accept any parameters and therefore does not send any.
Old question so I know this won't help the OP but hopefully it helps someone.
Without seeing your code (both the PLSQL and Java side), I would have to say that the procedure has required parameters (no DEFAULT value for a parameter) that you are not supplying in the Java code or the name of the parameter in the procedure does not match the name you used in Java.
Procedure Spec
PROCEDURE procedure1(value OUT NUMBER,
userId IN NUMBER,
returnCursor OUT PackageA.Types.cursorType);
Java-Code
SimpleJdbcCall optOutCall = new SimpleJdbcCall(dataSource)
.withSchemaName("Schema-A")
.withCatalogName("PackageA")
.withProcedureName(procedure1)
.declareParameters(new SqlOutParameter("value", Types.NUMERIC),
new SqlParameter("userId", Types.NUMERIC))
.returningResultSet("returnCursor", new UserMapper(EnumType.EMAIL, userId));
This "procedure1" exists in Schema-B but i have created a synonym for this procedure in Schema-A and i am trying to execute this procedure
using 'Schema-A' but it throws error, if i give the schema name "Schema-B" in java code then it executes correctly and returns the results.
Related
I'm trying to execute Snowflake Stored Procedure in Matilion Using Sql Script component.
But i'm getting error as Unknown user defined function.
Can someone help me to call the procedure using Matilion Job.
Thank You !
That looks like a name resolution error. Snowflake does not recognize the name of the stored procedure. You will see the same generic error message when trying to call a procedure that really does not exist...
You most likely need to
qualify the procedure name with a database and a schema
put the names inside double-quotes if they are case sensitive.
In the Matillion stored procedure article there is an example CALL "${environment_database}"."${examples_schema}"."audit"('START', ${run_history_id}, NULL)
My Procedure
The errors I am getting.
Check your schema.table_name. On your insert statement, you have MEMBER_ONLY yet on your update, you have MEMBERS_ONLY (Plural).
Also, if I am not mistaken the top part is also incorrect.
CREATE PROCEDURE procedurename
(
#paramname int
)
As
This is, obviously, Oracle.
Error stack points to exact error place, e.g.
Error(22,29): PL/SQL: ORA-00942: table or view does not exist
-- --
^ column 29
|
line 22
It would be easier to spot it if you chose to display line numbers in SQL Developer (do so; right-click the left margin and set it). I'd say that it is about member_system.member table. Another one, in the same from clause, is prospect_staging.magi_applicant.
It is unclear which user you're connected to (one, or none of these), but - comment you posted in deleted answer:
It works in the workbench but when I place it in the procedure it says the table or view isn't created
suggests that you might have got access to the table via role (and not directly to your user). Why? Because privileges acquired via roles work at SQL level or in anonymous PL/SQL blocks, but won't work in named PL/SQL procedures or functions - and that's what you have, a procedure named get_magi_applicant_data.
So, what to do? Grant privileges directly.
As of another error you got:
Error(31,9): PLS-00201: identifier 'V_INSERT_OR_UPDATE' must be declared
Looks like it is about if v_insert_or_update is null then line. Error isn't obvious; there is v_insert_or_update local variable declared in the procedure, so I can't guess what might be wrong here.
I believe this question is very trivial. I' unable to select rows inside a stored procedure that I defined, nor inside a UDF. Here is the syntax that I used:
Create Or Replace Procedure GenerateSequence(
In InternalUnitID SmallInt,
In ObjectTypeID SmallInt)
Language SQL
Dynamic Result Sets 1
Not Deterministic
No External Action
Modifies SQL Data
Commit On Return Yes
Begin
Select Number
From Sequence
Where InternalUnit=InternalUnitID
And ObjectType=ObjectTypeID;
End
If I try to create the above procedure (by putting the definition in a SQL file and running it). I get the following error message:
DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned:
SQL0104N An unexpected token "Select Number From Sequence Where Intern" was
found following "n Return Yes Begin ". Expected tokens may include: "".
LINE NUMBER=21. SQLSTATE=42601
Any clue what can be the cause of this problem?
My environment is DB2 10.5 Express on Windows.
My problem was that I needed to use a cursor in order to return the result set to the caller of the stored procedure.
References:
CREATE PROCEDURE (SQL) statement
Compound SQL (compiled) statement
I have created a stored procedure and compiled it successfully without any errors. However, when I call it within an annoynmous block, it returns an error message PLS-00201: identifier 'DUE_FOR_RAISE' must be declared.
What seems to be wrong? Is there something wrong with the procedure calling?
This is what I used to call the procedure:
BEGIN due_for_raise('Austin'); END;
It's because you've quoted your procedure name (never do this). You need to call it with quotes and exactly the same casing as you used to name the procedure, so:
BEGIN
"due_for_raise"('Austin');
END;
If would be easier to drop your old procedure, and re-create it without a quoted name.
To quote from the documentation on Database Object Names and Qualifiers:
Oracle does not recommend using quoted identifiers for database object names. These quoted identifiers are accepted by SQL*Plus, but they may not be valid when using other tools that manage database objects.
How can I call a stored procedure in the same schema without specifying the full schema name when coding another stored procedure. These are SQL PL procedures within DB2.
First SP:
CREATE PROCEDURE MYSCHEMA.SP_TEST
LANGUAGE SQL
BEGIN
END
Creating a SP calling this SP directly without a schema name causes a compilation error:
CREATE PROCEDURE MYSCHEMA.SP_TEST2
LANGUAGE SQL
BEGIN
CALL SP_TEST();
END
It will throw:
No authorized routine named "SP_TEST" of type "PROCEDURE" having compatible arguments was found.. SQLCODE=-440, SQLSTATE=42884, DRIVER=3.53.71
Directly giving the full schema name works:
CREATE PROCEDURE MYSCHEMA.SP_TEST2
LANGUAGE SQL
BEGIN
CALL MYSCHEMA.SP_TEST();
END
However if I ever move to a different schema I will have to replace that references all over the place. Is there a suitable workaround or nicer solution to the problem?
The CURRENT PATH special register is used to resolve calls to unqualified stored procedures and functions. CURRENT SCHEMA is used to resolve unqualified object names.
By default, CURRENT PATH has IBM functions plus your AUTHID:
$ db2 "values substr(current path,1,60)"
1
------------------------------------------------------------
"SYSIBM","SYSFUN","SYSPROC","SYSIBMADM","IBJORHOV"
1 record(s) selected.
You can modify this with the SET CURRENT PATH statement.
When you create a stored procedure, DB2 takes note of the value of CURRENT PATH at compilation time and uses them to resolve unqualified stored procedure and function calls within the stored procedure. The same logic applies for CURRENT SCHEMA and unqualified table names.
So the proper way to allow unqualified procedure and function calls within a stored procedure is to set the CURRENT PATH register and then creating the procedure.
Ommitting SCHEMA name is discouraged. Keep your schema names in your calls. If you move to a different schema, you have to do this by extracting/altering the SQL script anyway.
The SET SCHEMA command allows you to change the current schema:
SET CURRENT SCHEMA FOO;
CALL MY_PROC_THAT_RESIDES_IN_FOO();
It is not so easy to use set the schema to a dynamic value, though. You would have to either:
Do something with host variables (if you are within a calling application) or
Build and execute a dynamic SQL statement string.
At that point it is probably becoming more trouble than it's worth.
More information can be found at the documentation for the SET SCHEMA command.