Netezza Stored Procedure Array of Integers Input Parameter - netezza

I would like to define a stored procedure that receives an array of intergers as an input. Something like this:
CREATE OR REPLACE PROCEDURE "x"(DATE, DATE, INT[] , INT[])
Also, I want to execute it but I do not know how to write it?
Maybe like execute x(date1, date2, (1,2,3),(4,5,6))
This pops up an error:
ERROR [42000] ERROR: 'Exec "x"('2011-8-1','2015-9-14',(6,7,1),(1,2,3))'
error ^ found "," (at char 73) expecting IN' orNOT' or OVERLAPS' orOp' or `CONCAT_OP'

If you want to pass an array of values in a single parameter position, this will typically have to be done by packing them into a VARCHAR (as it seems you may have already figured out by your later question).
If you need more sophisticated array handling, then you can bring to bear the array functions available in the SQL Extension Toolkit.

Related

Accessing to OUT parameter (t_cursor type) from stored procedure using go and InstantClient

I'm dealing with an Oracle DB, connecting from go via InstantClient (version 11) (https://github.com/mattn/go-oci8). I need to be able to load this object and browse results... t_cursor output parameter.
I have tried many strategies, I know how to map function parameters to go structures but I don't know how to work with t_cursor type since it seems not being implemented in InstantClient
Example of stored procedure
create or replace procedure EXAMPLE(a IN NUMBER, b IN NUMBER, c OUT T_CURSOR) AS BEGIN
[Edit] We have also tried to execute SQL blocks from code to try to handle this third parameter.
i.e.
If you add something like
declare
c t_cursor;
begin
EXAMPLE(:1, :2, c)
end
then I don't know how you can get the block to return a result set that contains the cursor.
declare
c t_cursor;
begin
EXAMPLE(:1, :2, c)
select 1, c from dual
end
The whole block returning the result of that select would be ideal but oracle blocks do not return result sets afaik.
Anyone who can bear a hand on this?
Thank you very much
It can be done with the driver https://github.com/rana/ora instead.
*Rset may be passed to Stmt.Exe when prepared with a stored procedure accepting an OUT SYS_REFCURSOR
The README.me even has that exact example.
Caveats:
It's unclear whether the database/sql interface may be used or you are limited to the lib specific API.
Instant Client gets restricted to versions from 12.1.0.1.0 on.

SSIS Execute SQL Task - Input String in wrong format

I have an Execute SQL Task which tries to execute a stored procedure, like this:
EXEC usp_stored_proc ?, ?, ? OUTPUT, ? OUTPUT;
I have 4 variables mapped to parameters. Ignoring the output parameters, these are both strings mapped to NVARCHAR params (as expected by the stored procedure).
When I run the package, an error tells me that execution failed with the message input string is not in the correct format. However, when I use a breakpoint to find the runtime values of the input parameters (or at least the variables mapped to them) and execute the same line of SQL in SSMS using the runtime values, it works fine.
Can anyone help? I'm at the end of my tether with this. I can't even find out the exact parameter causing the issue although it's probably both as the values follow the same format.
More details:
Connection type: OLE DB
Input Variable: String = schema.table
Mapped Param: NVARCHAR, ParamName = 0, ParamSize = -1
UPDATE
Solved the issue by making a new execute sql component that calls a stripped down procedure. I then slowly added lines of code to the procedure and additional parameters until arriving at the same component I started with and now it works. Comparing the original and rebuilt tasks, I see absolutely no differences (same with the procedure), so I don't know why this issue was occuring.
Try changing the parameter size (ParamSize) to match the parameter size within the stored procedure; if nvarchar(50) then set it to 50.
Solved the issue by making a new execute sql component that calls a stripped down procedure. I then slowly added lines of code to the procedure and additional parameters until arriving at the same component I started with and now it works. Comparing the original and rebuilt tasks, I see absolutely no differences (same with the procedure), so I don't know why this issue was occurring.

Calling Stored Proc with CHAR Parameters results in a parameter with a huge value

I am calling a stored proc [MS SQL] using EF5 from a .net application
The call from EF
return base.ExecuteFunction<sp_select_contracts_Result>("sp_select_contracts", x, y, z);
in the proc the parameter is defined as #para1 CHAR(2) etc
But in SQL Profiler I caught EF sending the following
exec [dbo].[sp_select_contracts_statistics] #x='15 '#y='24 ',#z='2010 '
Exactly like that - a huge amount of spaces after the actual value.
When I change the CHAR to VARCHAR it works correctly:
exec [dbo].[sp_select_contracts_statistics] #x='15','#y='24,#z='2010'
I could work around this easily, but I would like to know what I am missing
here.
Update:
Forgot to mention that in C# all the values are strings.
In the last call from c# before going through EF the values are correct:
x = "15" {String} etc..
Edit2:
Changing CHARS to VARCHARS worked as expected. Would still prefer to know if this is a bug or just something we are missing.
When you define a char parameter, you have to define the max length otherwise it is going to do something weird. It defaults to putting white space for all the other characters not defined for the full length of the max size. I'm guessing the max size default for EF for a char here is pretty big:
var parm = new SqlParameter("x", SqlDbType.Char, 2);
parm.Value = "15";

PLSQL procedure OUT param - Arrays vs Cursor

I want to read a OUT param of a PLSQL procedure, to get the list of usernames.[Just a list of names, each name is a String]
This PLSQL procedure can return this Output in 2 ways:
Return as Array [Table of RAW]
a Cursor
My question is , what is the best datatype of the OUT parameter to be used in the PLSQL procedure? Is it Array or Cursor?
I was told Array is the best one, as You will get the array in one shot when you read the OUT param value. But In the case of Cursor, you just get a handle to the cursor pointer and you infact 'iterate' over it to read next elements.
Please clarify. Thanks
Update: Updating with more details for better clarity of the context.
I'm calling this Stored Procedure from a Java program [thru Oracle driver OJDBC], The purpose is to call the SP and get the resultant list of String and display the list in one page. The resultant list will contain an average of 50 and maximum of 100 elements.

Trying to escape a sp_executesql variable

I've run in to a problem with a software I'm configuring. I do not have access to the source code, only the config.
The issue is as follows, in the configuration the software expects me to enter a string, but I would like the string to jump out of the compare and instead execute a funtion.
Using sql profiler I get something like this:
exec sp_executesql N'SELECT * FROM dummyTable WHERE (Name LIKE #Pattern)',N'
This does not work in my setup, because pattern is not clearly defind in advanced. I need to take the
variable passed as pattern and run it trough a sql function but I can't figure out how. Typically Pattern contains a single char, in my example "1". I've tried altering the Pattern to use an escape char and run my function on it, but I think I'm missing someting (If this is at all possible).
The variable I've send from config is as follows:
{0}' or Name like dbo.RunCalulation({0})
Giving me the following:
'…#Pattern nvarchar(43)',#Pattern=N'1'' or Name like dbo.RunCalulation(1) '
This executes, but does not give any response, so I think the esacpe char does not work, and it compares the whole string to Name.
I'm real stuck at this, hope someone has a good idea what to do (I know that not having the source code is a real problem here.
One of the huge advantages of query parameters (such as #Pattern) is that they help protect against SQL injection (which is what you are trying to do).
So the answer is that you cannot do what you want. There's no way to escape the #Pattern parameter and add some of your own SQL to that query, because everything you pass as #Pattern will be interpreted as data, and never as SQL command text (which is the reason why your SQL text ends up inside the single quotes, and why your quote is automatically escaped to ''.).

Resources