I'm creating Stored Procedures to replace Legacy app programs for an IBM i. I'm calling the stored procedure from a Java Web App. I'm using the jt400 JDBC driver
My JDBC URL is jdbc:as400://myhost/;libraries=*LIBL,MYLIB;prompt=false
The stored procedures can call stored procedures
The initial stored procedure call completes normally if it does not make further stored procedure calls
If the stored procedure makes a call to other stored procedures it fails with
com.ibm.as400.access.AS400JDBCSQLSyntaxErrorException: [SQL0204] MY_SP in MYLIB type *N not found.
If I hard code a schema in the stored procedure call statement, the call completes normally.
I want to have the called stored procedures use the same schema as the caller
You need to SET PATH = "MYLIB"
When I am using SQuirreL to call a stored procedure, I need to use the SET PATH statement to get it to find the stored procedure. I don't know if that is because my library list is bad or what, but the current schema is not used to find an unqualified stored procedure.
I actually had this same problem, the stored procedure uses your job description library list. You need to edit that you can use TAATOOL CHGLBLJOBD. I am not in front of an iSeries at the moment but I believe the command was either EDTJOBDLIB or EDTJOBDLIBL WRKJOBDLIBL. It is some variation of that.
Related
I want to execute a single instance of Snowflake stored procedure by using Snowflake code only. Trying not to use tasks as it has external dependencies.
Just by code. Throwing all stored procedure instances in parallel.
For example SP_INSERT_WORDS(VARCHAR) is a stored procedure and I want to call multiple instances of the same stored procedure.
SP_INSERT_WORDS('A');
SP_INSERT_WORDS('B');
SP_INSERT_WORDS('C');
. . .
SP_INSERT_WORDS('Z');
You can try the below options
Use the RESULTS option in SnowSQL.
!set results=False;
This option avoids the wait on the previous calls and asynchronously execute queries
Task execution may be viable, however it is unidirectional
Parallel calls from the application
Link on restrictions for Stored Procedures
https://docs.snowflake.com/en/sql-reference/stored-procedures-usage.html#restrictions-on-stored-procedures
I'm trying to create a trigger on derby which simply calls a procedure. The stored procedure does not change anything and gets no parameters. It simply check that the time is within an interval (for example between 08:00 and 16:00). On creation of trigger i receive the following error:
"42Z9D: Procedures that modify SQL data are not allowed in BEFORE triggers."
But the procedure makes no changes.
When defining a procedure one should specify if the procedure modifies data or not. If it executes any sql or not. As mentioned in the link provided above by Bryan I should use one the options:
{ NO SQL | MODIFIES SQL DATA | CONTAINS SQL | READS SQL DATA }
If you dont use this options the default value will be assumed that is CONTAINS SQL.
I just wanted to know what is the best practice to create and execute a stored procedure.
I have seen like below:-
IF EXISTS (SELECT * FROM sys.objects WHERE type = 'P' AND name = 'Foo')
DROP PROCEDURE Foo
GO
CREATE PROCEDURE dbo.Foo
But I am thinking when we execute this stored procedure, it will drop the stored procedure and create a new one. But if there is error in the create stored procedure syntax, it won't recreate the stored procedure, right? So as a result our existing stored procedure is deleted and new stored procedure is not created. So what is the real reason for adding DROP here?
The reason is so that your scripts can be run in an idempotent way - they can be run as many times as needed, with the same result. Namely, your database will have the stored procedure you desire. Your procedure will be created, and dropped beforehand if needed. If you didn't do this, then you'd need separate drop and create scripts.
If you're concerned that your scripts have errors, well, fix them. Run your scripts a few times, and fix any problems that arise. The effort is worth not having to maintain separate sets of scripts.
BECAUSE it is execute in line by line manner so when it create procedure and then error comes and again you recreate that procedure then it gives error because it is already generated in your database with error code....
so for this it want recreate that procedure again.....
you can use alter instead of create....
Hope this help you...
I looked around in manuals on how to use cursors in DB2. However I am still unsure how to implement the following screnario:
caller: a client SQL calls the stored procedure and loops through the values in cursor
stored procedure: the stored procedure being called selects rows from a specific column
Is the cursor declared in the caller or the stored procedure? Sometimes I see the cursor being declared in the caller script, other times the cursor is declared in the stored procedure making the row select. Either way is fine.
Your stored procedure will define the cursor and return it to the calling application.
There are 2 requirements to do this:
When you create the procedure you specify RESULT SETS n to tell DB2 that the procedure will return result sets to the client application.
When you declare the cursor in the stored procedure, you must specify the WITH RETURN option to indicate that this cursor will be passed back to the calling application.
OPEN the cursor within the stored procedure.
If you read the documentation for the CREATE PROCEDURE statement, there is an example at the bottom of the page that shows this.
I have a stored procedure that uses table variables to create a query and runs perfectly when executing in SQL Server Management Studio. However, the column referring to this table variable does not display when running the stored procedure in Query Designer.
I have used this method on many other reports without issue, but cannot figure out why the value will display in SSMS and not in SSRS.
After a fresh nights sleep, I realized it was how a parameter was being passed to the Sub Stored Procedures. The main stored procedure had a where clause that contained a "LIKE #Parameter" but the Sub Stored Procedure contained an "= #Parameter", so when a "%" was passed into the parameter the main Stored Procedure returned results, but nothing was displayed from the Sub Stored Procedure.
Simply just a case of making my job harder on myself...