Report Builder Report from Stored Procedure returns empty tablix rows - sql

I have a relatively simple stored procedure which is just a select statement from 2 joined tables, and has a single parameter.
Running it in SSMS returns, for example, 6 rows.
In Report Builder, I created a dataset from this SP, and I added the fields manually in the Fields tab, using the same names as in the SP.
I pull the fields to a tablix - which returns empty rows, but interestingly - 6 empty rows. So it works fine in SSMS and Query Designer - but nothing when executing.
I have tried creating a brand new report from scratch, and I have checked for white font on white background - no result.
Any clues what could be the reason?
thanks in advance,
PS Value property:

Related

SSRS Not Displaynig Columns and Values

I'm practising SSRS and I'm having an weirds issue.
I'm creating a simple query where it returns 3 columns from the Product table from the Adventure Works Database.
However, the column and rows are blank. I then created another rdl, this time with the Wizard and it's working fine.
When I run my query in the query editor, the information is displayed.
Any ideas?
I believe I found the answer.
Resizing the table seems to refresh something and the values are not been displayed.
Really weird bug. I had tried before, deleting and adding the table, closing Visual Studio, creating a new RDL.

SSRS conditional execution of dataset

I have two different datasets in SSRS report which gives different number of output fields.I have used this two data set into two different tables in report.
1) One table will display output at a time in execution based on condition.
Actually while running the report two datasets are executing the SP and it takes more time to display the output.
Requirement:
I need to execute the one dataset SP at time based on condition.Other Dataset SP should not Execute.
Example:
Dataset1 executes Sp1
Dataset2 executes Sp2
Table1 uses Sp1
Table2 uses Sp2
Normally while executing report Table1 will display output(Based on default parameter selection)
But SP1 and SP2 are executing on same time.so report takes more time to display output.
I need to execute 1 SP at a time based on condition.so that other dataset SP will not execute.
Step1:
First Create Dummy SP for Dataset .That SP should have same input parameters and same output fields as original SP1 but gives zero output rows.Do the same for SP2 for Dataset 2
Step2:
In Dataset properties select StoredProcedure Icon and in Fx column add below code
=IIF(Parameters!ManagerID.Value= -1,"SP1","DummySP")
Note: DummySP created should be same like SP1
Do the same for Dataset 2..and this works.
I have seen this answer, it's nice, but to create two SP's, it is sometimes very cumbersome. Sometimes the report uses a SP's many. This means that all SP's must be duplicated. And if you double the reports many... This means that they need to be maintained and improved throughout their lives.
Instead I have another solution:
Step 1: I create one SP, and use one of the parameters that already exists anyway.
Step 2: In the mapping of the DS\Report's parameters, instead of sending to DS the parameter sent to the report as it is, you can write an expression, which says that if I want to display the data of this SP I send the parameter sent to the report, and if I do not want to display this data, I will send different parameter , Which will cause the SP not to return data.
All this of course only if it is a procedure with parameters that allow the above. It is also possible to create a special parameter for this.
The following is a picture and example of an expression:
and the expression:
=IIf(Parameters!Display_xxx.Value=1,Parameters!yyy.Value,0)
You must control the visibility of tablix depends on the received parameter, in additional you can create parameters on both queries to control where execution to avoid the execution, like
Where #Condition = 1 AND ( Your WHERE )
As for that sack of performance, you don't want to run other SP at all, in this case, as per my experience, the best way is to modify your stored procs to add a new parameter based on what you are deciding what data set to call (means what data to pull).
So that, if the parameter says that the specific SP is not required, don't run the code in SP using IF-ELSE combo and return blank single row.
And then, on top of that, you can hide or show your tablix.
Hope that makes sense?
And if the column count and data types are same, you can always use an expression to decide what stored-proc to call.

Trim Funtion in Dataset Stored Procedure Causes SSRS report Fail

I have an SSRS report. It have multi valued parameters & a sub report. It runs fine until I changed the dataset for a parameter ( In both report). When I previewed the report it shows below error.
"one or more parameters were not specified for the subreport located
at /report".
I tried below steps to resolve the issue
1. Ensured parameter names are correct.
2. removed rdl.data file
3. Deleted the dataset and recreated it.
I tried to revoke the changes made in dataset & the report runs perfectly. The only change I have made in the dataset was the addtion of LTRIM(RTRIM)) Function in dataset query to remove the spaces between multi-value parameter.
The dataset query was like below
select Loan_no
From loan_header
where rowatatus = 'A'
I have changed it into
SELECT LTRIM(RTRIM(Loan_no)) As Loan_no
From loan_header
where rowatatus = 'A'
When I removed LTRIM(RTRIM) Function from the Dataset query, the report works fine. So, use of LTRIM(RTRIM) Function causes the Report failure.
What will be reason behind this? Anyone facing similar issue before?. Please help.

Access Form Textbox as Input query to ODBC source returns empty dataset

I have an Access 2010 utility that is designed to query an Oracle DB via ODBC connection as Linked Tables. I created a simple form with two textbox's and a command button. The command button launches VBA code "DoCmd.OpenReport".
The report query Where clause looks like this:
WHERE (((PRODLAW_ITEMLOC.LOCATION)=[Forms]![frm_Qry_ByItem&Loc]![txtLocation]) AND ((PRODLAW_ITEMMAST.ITEM)=[Forms]![frm_Qry_ByItem&Loc]![txtItem]));
the values of txtItem and txtLocation are the user supplied values from the form.
This returns an empty dataset as it is now. If I query a local table, (using a single ODBC query to extract all possible values into a single local table) this method works without any issue other than the 8-10 minutes it takes to refresh the local table. If I replace the query criteria "[Forms]![frm_Qry_ByItem&Loc]![txtItem]" with a simple direct value like "1234" (assuming 1234 is a valid item number), it works without issue.
I've tried to explicitly convert the value of the textbox like "Cstr([Forms]![frm_Qry_ByItem&Loc]![txtItem])" but it made no difference. As this is a query, I can't simply create a breakpoint and examine the properties of the variables so I'm left scratching my head. I've spent hours searching SO and other sites for clues but found nothing related.
Please advise. Thanks!
mfc

Using SQL Stored Procedure as data for a Microsoft Dynamics CRM report

We need to have a semi complex report in CRM that displays some accumulated lead values. The only way I see this report working is writing a stored procedure that creates a couple of temporary tables and calculates/accumulates data utilizing cursors. Then is the issue of getting the data from the stored procedure to be accessible from the Reporting Server report. Does anyone know if that's possible? If I could have the option of writing a custom SQL statement to generate report data, that would be just excellent.
Any pointers ?
Edit:
To clarify my use of cursors I can explain exactly what I'm doing with them.
The basis for my report (which should be a chart btw) is a table (table1) that has 3 relevant columns:
Start date
Number of months
Value
I create a temp table (temp1) that contains the following columns:
Year
Month number
Month name
Value
First I loop through the rows in the first table and insert a row in the temptable for each month, incrementing month, while setting the value to the total value divided by months. I.e:
2009-03-01,4,1000 in table1 yields
2009,03,March,250
2009,04,April,250
2009,05,May,250
2009,06,June,250
in the temp1 table.
A new cursor is then used to sum and create a running total from the values in temp1 and feed that into temp2 which is returned to the caller as data to chart.
example temp1 data:
2009,03,March,250
2009,04,April,200
2009,04,April,250
2009,05,May,250
2009,05,May,100
2009,06,June,250
yields temp2 data:
2009,03,March,250,250
2009,04,April,450,700
2009,05,May,350,1050
2009,06,June,250,1300
Last column is the running totals, which starts at zero for each new year.
Have you considered using views. Use a heirarchy of views if it is very complicated. Each view would represent one of your temporary tables.
EDIT Based on comments
I was thinking of SQL views, basically the same SQL as you would have written in your stored procedures.
I haven't done this - just thinking how I would start. I would make sure when the stored procedures populate the temporary tables they use the Filtered views for pulling data. I would then set the access to execute the SP to have the same security roles as the Filtered views (which should be pretty much to allow members of the PrivReportingGroup).
I would think that would cover allowing you to execute the SP in your report. I imagine if you set up the SP before hand, the SSRS designer has some means of showing you what data is available and to select an SP at design time. But I don't know that for sure.
First, since most cursors are unneeded, what exactly are you doing in them. Perhaps there is a set-based solution and then you can use a view.
Another possible line of thought, if you are doing something like running totals in the cursor, is can you create a view as the source without the running total and have the report itself do that kind of calculation?
Additionally, SSRS reports can use stored procs as a data source, read about how in Books online.
I found the solution. Downloaded Report Builder 2.0 from Microsoft. This allows me to write querys and call stored procedures for the report data.
Microsoft SQL Server Report Builder link