I am migrating BIRT reports from version 2.6 to 4.4 and facing a very strange issue which is as under
BIRT parameter passed as part of the query gets rounded off i.e if I pass 1 as parameter, query gets executed for 0 and if I pass parameter as 99 or 101, the query gets executed for 100
Query - select data from table1 where actualID = ?;
The datatype for parameter is Decimal (28,0)
DB used is SQL Server 2012
I have logged the value of parameter in BIRT Functions (beforeOpen, beforeClose and others) and it always show the parameter value consistent with what I have passed.
Please help me understand or point me to a direction where I can take this investigation further
Any help will be much appreciated
Note
If I convert datatype from Decimal to String, it works fine
If I pass parameter as part of Query it works fine but it doesn't work when parameter value dynamically replaces '?' in the query
You should also log the parameter values in the afterOpen event.
Maybe they are modified somehow in the beforeOpen event.
In my BIRT framework, I have defined a function like this:
afterOpen: function(ds) {
log.debug("afterOpen DS " + ds.getName() + " inputParams=" + ds.getInputParameters().toString());
}
This function can be called as trace.afterOpen.
Then I can use it in the data set's afterOpen event like this:
trace.afterOpen(this);
You could also set BIRT's internal logging to FINEST; that will generate loads of debug messages and should include the bind variables for each SQL statement executed AFAIK.
Related
I tried to get value from query or to specify values, as soon as the parameter is multi value i can't see the data when i'm trying to make my subscription.
my request looks like :
select id from employee where canal in(#canal)
what should i do, i'm totally stuck,
when i did research i saw data driven subscription but i don't have access to it apparently, don't know if that help
I'll start by saying sorry this isn't a pleasant answer. You've run into a limitation with the built-in functionality. Thankfully there are workarounds.
The problem is that you can only pass 1 value into the data-driven subscription. So you have use a comma-separated list and get the query/report to parse out the values.
If you have or can create a Split function in your database, that is a good option. This would be a table-valued user defined function and there are some easy to find examples already. Also this function is generally good to have for other use cases anyway. With this your SQL would read:
where canal in Split(#canal)
SSRS works really well with SQL Server, but when you use an ODBC connection, the parameter support is limited. You can use the same multi-value parameter workaround that is required in those cases.
In the Dataset properties > parameters tab, use an expression like this to combine the values into a single comma-separated string surrounded by commas.
="," + Join(Parameters!canal.Value, ",") + ","
The SQL would look like this:
where # like '%,' + canal + ',%'
Basically, this searches row-by-row for values that are contained in the string.
In either case, the query in your data-driven subscription settings will need to return the comma-separated string. Then you can select that column in the report parameters value field. Hope this helps!
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.
I’m experiencing a frustrating issue when trying to call a proc in an OLE DB source task. I’m using the SQL command from variable data access mode but I can see that it isn’t evaluating my variable correctly.
My variable (with ValidateAsExpression set to True) uses an expression to create a sql command like “EXEC ProcName ‘Param'” where the value of Param comes from a variable who’s value I set using an EXEC SQL task. Below is the expression:
“EXEC ProcName ” + “‘” + #[User::vDateThreshold] + “‘”
If I use a variable in my source that references a static value it works fine, but the issue seems to be when I use a variable which reference another variable in its expression.
Has anyone else come across this issue?
I’m using this method because I’ve had a similar issue when trying to use a parameter with the sql command data access method.
Thanks in advance
I’m using this method because I’ve had a similar issue when trying to use a parameter with the sql command data access method.
The right way to do that is by using SQL Command with parameters:
EXEC ProcName ?
And select #[User::vDateThreshold] as parameter.
Parameterized OLEDB source query
If it is not working then check your procedure code and make sure it generate a specific result set. If the result set is dynamic and columns are not fixed then you have to define it in the query using WITH RESULTSETS keyword.
https://www.mssqltips.com/sqlservertip/2356/overview-of-with-result-sets-feature-of-sql-server-2012/
From the name of #[User::vDateThreshold it seems like an SSIS datetime variable. Try setting this to a variable with an explicit cast and then executing the stored procedure with the variable. Make sure there that are single quotes (') within the CAST function as you would use if this was done in SSMS. When concatenating a datetime variable within a string variable in SSIS, the datetime variable must be converted to text, which is done with (DT_STR, length, codepage) in the sample expression below. I'm not sure what version you're using, but testing this out on SSDT for Visual 2017 worked fine for me. This will cover if you still want to hold the SQL in a variable, however the solution that #Hadi posted is a good option if you'd prefer to go that route.
"DECLARE #pDate DATETIME
SET #pDate = CAST('" + (DT_STR, 50, 1252)#[User::vDateThreshold] + "' AS DATETIME)
EXEC ProcName #pDate"
Thank you for the responses to my question.
I actually found the issue was with the ordering of my tasks in the package. When I looked closer at the values assigned to the relevant variables by using a break point on my exec SQL task I could see the wrong date was being passed to my proc. When I set the value of vDateThreshold at an earlier point the correct date value was assigned.
I think this was a case of looking at something for long enough that I was missing the obvious.
I'm working in report builder, calling a stored procedure that has a parameter that, when null, sets itself to a certain value. I want to display what this parameter is set to on the report. From experimenting, Report Builder's parameter collection only shows the parameter as it is sent from the report.
Alternatives that I've considered but can't get to work or are sub-optimal:
Adding the parameter to the select statement. The main drawback is this won't display a value if there are no results.
Using a return value or output parameter. There doesn't seem to be a way to do this.
Re-creating the "null" logic in the stored procedure. The correct output is displayed but this is a code fork.
How can I display this value? Is there a way to show a return value or output value?
You could change the procedure to return the parameter value in a UNION ALL select so that a row with the parameter value will always be returned. That row could have NULL for all the other columns so that you can filter it out in the rest of the report.
Another possibility is to add a second dataset to the report that does nothing but get the value of the parameter based on what you pass. That, however, is also a sort of code fork. The fork could be mitigated, however, by putting it in a UDF, and resourcing the same UDF in both datasets.
Yet another possibility is to replicate the logic of populating the parameter in a Custom Code block in the report. However, that is also a code fork.
I've never worked in Report Builder interface but I do have quite a bit of experience building reports in BIDS/VS... There it's a simple matter of setting the parameter default, in the rdl, to match the default in the stored procedure.
I've got a stored procedure with an int output parameter. If I run SQL Server Profiler, execute the stored procedure via some .Net code, and capture the RPC:Completed event, the TextData looks like this:
declare #p1 int
set #p1=13
exec spStoredProcedure #OutParam=#p1 output
select #p1
Why does it look like it's getting the value of the output parameter before executing the stored procedure?
The RPC:Completed event class indicates that a remote procedure call has been completed. So the output parameter is actually known at that point. See if tracing the RPC:Started shows you what you expect.
This is, no matter how you look at it, a bug. The intent of the SQL Profiler "TextData" is to enable someone to understand and repeat the stored procedure call. In this case, running this T-SQL can give you a completely different result, if the spStoredProcedure procedure has any logic dependent on the input value of the #OutParam parameter, where that value of "13" were somehow meaningful as an input value.
It's easy to see how it can be convenient (enables you to see the output values of the proc call, which would otherwise need to do with the "RPC Output Parameter" event), but it is effectively a "lie" as to what T-SQL equivalent was executed.
RELATED: I just came across an article from the Microsoft Customer Service and Support team - about another case where conversion of the RPC:Completed event's BinaryData into a displayable TextData value results in an inaccurate reproduction of the original RPC call - this time codepage issues:
http://blogs.msdn.com/b/psssql/archive/2008/01/24/how-it-works-conversion-of-a-varchar-rpc-parameter-to-text-from-a-trace-trc-capture.aspx
UPDATED: By experimenting with this, I found another peculiarity of the behaviour - the profiler will only use this incorrect initial SET if the input value for that parameter, in the RPC call, was Null. If a non-null value was provided (and the parameter, in .Net SqlClient, had direction "InputOutput"), then that initial SET holds the true input value, and not the resulting output value. But if the input was null, then the output value is set instead.
This observation supports the notion that this is simply a null-handling bug in the profiler RPC-to-TSQL display conversion.