Working with SSRS and a SQL 2000 source, I have a stored procedure that takes three parameters and returns a result set.
I have a dataset with the Command Type set to StoredProcedure and the procedure name in the Query String.
When I attempt to execute the procedure in Visual Studio/BIDS, the Define Query Parameters dialog box presents with each of the parameters from the procedure listed twice. Supplying values for the parameters and proceeding results in a too many arguments specified error.
How do I get SSRS to recognize and pass the correct number of parameters to the stored procedure?
I found a workaround for this problem:
Set the Command type to "Text"
Specify the procedure name and parameters:
EXEC procname #param1, #param2, #param3
"EXEC" and specifying the parameters are both requirements for it to work. The parameters can be named anything as long as they are prefixed with the "#" symbol. All parameters that require a value must be represented. Of course any optional parameters (those with defaults specified in the proc) must be represented in the command text if the report is going to reference them internally or present them as parameters for the user, but optional parameters do not have to be specified for the proc to run and return a result set.
check and make sure that you don't have extra parameters declared on the report, if you do delete the 2 extra and ensure that those are the ones being passed to the stored procedure.
also double check and make sure you didn't accidentally declare 4 parameters in the stored procedure.
So I know this is old but I did find a way to get to work and this is SQL Server 2000 (8.0.2039) Stored Procedure and SSRS Version 13.0.4224.16
I did with an expression:
="DECLARE #Month int; " & "DECLARE #Year int; " & "DECLARE #Format int; " & "DECLARE #SQL nvarchar(4000); " & "SET #Month = " & CStr(Parameters!iMonth.Value) & " ; " & "SET #Year = " & CStr(Parameters!iYear.Value) & " ; " & "SET #Format = " & CStr(Parameters!iFormat.Value) & " ; " & "SET #SQL = 'EXEC [dbo].[sp_MyProc] #Month = #Month, #Year = #Year, #Format = #Format'; EXECUTE sp_executesql #SQL , N'#Month int, #Year int, #Format int ', #Month , #Year , #Format"
I tried almost everything else I found and it would not link the parameters to the report until I did this above for the Dataset defined by Query Type: Text and using the function expression.
Related
I can't get Flyway 7.7.3 to parse the HyperSQL CREATE PROCEDURE statement below. Though it used to work I guess, with an older version, as this is a 2018 script that I'm trying to resurrect.
CREATE PROCEDURE proc_findByLastname(IN name VARCHAR(30)) READS SQL DATA
DYNAMIC RESULT SETS 1
BEGIN ATOMIC
DECLARE persons_by_lastname_cursor CURSOR FOR
SELECT * FROM persons WHERE last_name = name;
OPEN persons_by_lastname_cursor;
END;
I unsuccessfully tried to inline the different lines, to get rid of the "DYNAMIC RESULT SETS 1" line, and couldn't understand what I read from inside the parser in step-by-step debug mode neither.
This is the complete trace :
Caused by: org.flywaydb.core.api.FlywayException: Unable to parse statement in db/migration/V2__procedure.sql at line 1 col 1. See https://flywaydb.org/documentation/knownparserlimitations for more information: Incomplete statement at line 1 col 1...
The referred limitations doesn't seem to apply: I tried to change the variable's name.
I also tried to change the delimiter, still no luck!
DELIMITER /;
CREATE PROCEDURE proc_findByLastname(IN lastname VARCHAR(30)) READS SQL DATA
DYNAMIC RESULT SETS 1
BEGIN ATOMIC
DECLARE persons_by_lastname_cursor CURSOR FOR
SELECT * FROM persons WHERE last_name = lastname;
OPEN persons_by_lastname_cursor;
END/;
I am trying to call a stored procedure that takes in 3 inputs (State, Zip, & Distance). Upon submit of the search the values inputted will be put in the query string which is how I am trying to get them to pass to the stored procedure.
I decided to use a repeater with a custom query, which in my Query I have set up like this:
exec Republic.BranchesNearZip #zip = '{%zipCode%}', #state = '{%state%}', #miles = '{%distance%}'
with a transformation.
When I check my inspector I see the values in the response, but I keep getting, 'No Data Found', but If I were to hard code the values into the custom query it seems to work.
It does not work with macros like {% ... %} out of the box, this was already discussed here. You need to use sql query and sql macros, you can't use stor proc with parameters.
You cannot use macros in the query itself. However, you can still pass the macros to the query and pass them to your stored procedure.
Use the following query as an example (NOTE: Make sure the query type is "Query text"):
DECLARE #NumOne int,
#NumTwo int;
SELECT ##COLUMNS##
EXEC [dbo].[spAddTwoNumbers] #NumOne, #NumTwo
Then in the Select columns attribute of our repeater:
#NumOne = {% return 25 %}, #NumTwo = {% return 25 %}
The query parser will produce the following query as a result:
DECLARE #NumOne int,
#NumTwo int;
SELECT #NumOne = 25, #NumTwo = 25
EXEC [dbo].[spAddTwoNumbers] #NumOne, #NumTwo
In SAP HANA i can create a procedure with in and output parameters. Even without output parameter the procedure can output a table.
I notice three versions of output in stored procedures:
a select at the end of the procedure - without declaring the structure.
an output parameter out parameter varhcar(100)
an implicit table definition returns table (var1 varchar(10)) after function parameter and before keyword LANGUAGE SQLSCRIPT
What is the difference of these and how can I reuse each of these output parameters in other stored procedures?
The only one I am aware of is
call procedure(input1, input1, outputVar)
Unfortunately I don't know how to bound an SQL result to output parameters without creating a physical table.
Reason for this question
Issue 1
Function callBuildJoinOn returns empty result. Due to that loop in SP_BUILD_JOIN_ON is not executed - but the list is build in split string (both tested)
Proceedure callBuildJoinOn
...
in colTable1 nvarchar(200)
out columnsTable1 "SCHEMA"."package::TT.STRING_LIST"
call "SCHEMA"."package::SP_SPLIT_STRING"(colTable1, columnsTable1);
call "SCHEMA"."package::SP_BUILD_JOIN_ON"(:columnsTable1, :columnsTable2, :joinOn);
SP_BUILD_JOIN_ON
columnsTable1 "SCHEMA"."package::TT.STRING_LIST"
declare cursor columnList for
select * from :columnsTable1;
for col as columnList do
joinOn := joinOn || 'a.' || col.item;
end for;
Why split in two functions?
Declare of cursor results in compiler error if after a call statement
There is even a fourth option to get to a result set from a HANA SQLScript procedure: the result view (not supported anymore as of HANA2).
But let's not stir up more confusion.
The different options can be used in different scenarios:
Procedure IN/OUT parameters are used to get data into and results out of procedures. The OUT parameters can either be bound to other SQLScript variables (when you call the procedure from another procedure), or a HANA client can read the result sets that get created for each OUT parameter of type TABLE). For example, a JDCB client would find multiple result sets after the procedure execution and would fetch those.
Table functions, that are functions that return a table, can be used just like tables or views:
SELECT * FROM <tablefunction>( in_param1, in_param2, ...);
This provides an easy option to read back whole tables from functions or to simulate parameterised views.
The remaining option you mentioned is the so-called "default result set". This really is only useful for consumption in the SQL editor or in a HANA client that fetches all result sets after procedure execution. The default result set cannot be bound to any SQLScript variable and cannot be referenced in SQL commands.
Problem was that joinOn was defined as output parameter: out joinOn nvarchar(1000)
this resulted that:
the variable was null
the variable was not populated: joinOn := joinOn || 'a.' || col.item; resulted in null !
Solution
Change out to inout
initialize parameter joinOn := ''
We have a requirement to create a stored procedure in Oracle, passing input variables and output to be in JSON format. I've tried using listagg() but getting error as "result of string concatenation is too long" while executing the procedure.
The expected output has to be in JSON format from the procedure.
A regular select in PL/SQL uses bind variables by default and you might want to have a look at https://github.com/doberkofler/PLSQL-JSON to generate json.
used xmlagg and it worked
select
(SELECT RTRIM(xmlcast(XMLAGG( XMLELEMENT(E, columnname|| ',') ) AS clob) ,',')
FROM table) ||'}' from dual
The included code pulls parameters from a form and executes a stored procedure. The result is captured via a list box object and displayed on the form. How can I parse the result from the stored procedure, modify values, and then submit it back so the list box shows the updates?
My stored procedure returns a list of user accounts and their status (1,0). What I want to do is update the status from 1,0 to true,false so that when the results are shown in the form, the listbox shows true and false as opposed to 1,0.
Dim paramAcctNo As String
Dim paramProfileId As String
Dim query1 As String
Dim query2 As String
'Populating the form parameters
paramAcctNo = [Forms]![frm_userlookup]![lst_searchresults]
paramProfileId = [Forms]![frm_userlookup]![tb_hidden]
'Executing SP
query1 = "EXEC dbo.sp_ADCON_userDetailView '" & paramAcctNo & "','" & paramProfileId & "'"
'assigning results to listbox to display in form
Me.listbox1.RowSource = query1
If you are allowed to change the actual values in the query1 table after your stored procedure has run, you can run two simple UPDATE queries to change the 1s to True and the 0s to False.
UPDATE query1 SET [field name that contains the 1] = "True"
WHERE ([field name that contains the 1]="1")
UPDATE query1 SET [field name that contains the 0] = "False"
WHERE ([field name that contains the 0]="0")
A problem that you might run into is with a Type mismatch error. If the field containing the 0s and 1s is numeric, you won't be able to update it to a string value.