I face one interview question on SSRS which I don't know the answer.
How many connections/datasets required for parameterized report in SSRS
This is a bit of a strange interview question and implies you've never used SSRS - but nevertheless, to answer your question the minimum is 1 connection to a server, 1 dataset and 1 parameter. I suggest you create a report and use this as a starting point to increase your understanding.
Related
Requirement: We are trying to build PowerBI report using SSAS Cube as a source.
Currently we already have the same report in SSRS which is using the same cube as source.
so we are upgrading to Power BI as per the user's need and the SSRS report will be decommissioned after successful implementation of this.
The SSAS cube also has some complex calculations (calculations tab of the Cube) which are used in the SSRS report.
There are many columns which have been hidden too but are called into the SSRS Dataset.
The current SSRS report dataset has an MDX query(including some of the hidden columns) which serves as the Main query for report (Matrix type report with row groups and column groups), along with other smaller datasets which supply values to parameters
The MDX query in the SSRS report has around 6 parameters(which user can choose the values from the SSRS parameters prompts)
We are trying to find all the possible ways so that we can build the report in PowerBI
Our findings and what we have tried so far :
1)We have tried live connection after unhiding the columns (only those ones which are called in the MDX query) but we could not perform any transformations or calculations due to Live connection limitation. We thought about creating possible calculations with in the Cube level but don't know if it would actually give us the desired results correctly which would match with existing SSRS report as a comparison.
2)We tried Import mode using the same MDX query which is used in SSRS report by supplying values to the parameters(for example we passed [Report ID].[Report ID].&['a specific City name'] replaced with [Report ID].[Report ID].Children, so that we get data for all the cities instead of just 1 city) but the results are coming out incorrect.
Please if someone can provide us a valid approach on the architecture part, it would be really helpful as it will help us to get started.
Please let me know if something is not clear, so I can add more to this
I have a bear of a problem here. The user wants a report that shows the earnings, deductions and liabilities (EDL) code of each employee or null/blank if an EDL code doesn't apply to that employee. I needed one row for each employee name and columns for each possible EDL code combination. I got that answer fixed from my previous question here:
Struggling with a dynamic pivot on multiple columns with one being concatenated
I ran into a problem where there are a potential 270 column headings (EDL code combination with "subj", "elig" or "amt" appended) but not every employee will have a value for every column and security settings lock me out of seeing 1 of the 3 payroll groups. This made my report very limited in that when I ran it I could only show on the Crystal Report the data for what columns I had at the time I created the Crystal Report. Well, the user who requested this report has access to payroll group 1 and if even one of those employees had an EDL code that I didn't have in my data when I created the Crystal Reports file then the report wasn't useful to the user. We figured a way for her to get the info she needed by her logging into SQL Server and executing the stored procedure and she did what she needed to do with the data.
Fast forwarding to today I have to create this as a report in SSRS or give detailed instructions on how she can do this in the future if need be since my contract is coming to an end. I'm not familiar with SSRS but I thought maybe that would meet her needs over Crystal Reports. However, I'm running into the same problem. When I add the stored procedure as a dataset (adding it in as text to execute, not clicking the stored procedure radio button) I only see the EDL codes from that particular query not all potential combinations. I need a way to maybe dynamically add columns to the SSRS report, does such a thing exist?
Is there an issue with SPLIT(JOIN()) functions in SSRS 2012?
Here's why I ask...
I've just set up an SSRS 2012 server. I have an existing report I built in SSRS 2008 R2, which pulls from a 2005 database. I created a new project in MVS 2010 and added the existing rdl.
When I preview the report, the performance is at least 5 times worse than it is when I preview it in MVS 2008. I ran a trace and found that it took quite a while for SSRS to even execute the SP. Once it did, it rendered quickly.
I was trying to think of something that might slow down the SP's execution. The only thing I came up with is that I have a lot of multi-valued parameters I pass into the SP using SPLIT(JOIN()) functions. Have those been replaced by something new in 2012? If not, I don't even know where to start looking for the problem. My initial google searches have turned up nothing.
Has anyone experienced this problem or know of a list of things that worked well in 2008 but not so well in the new version?
I hope this question isn't too vague. Thanks for reading!
EDIT: I feel silly. I just traced the 2008 report execution and it turns out it does the same thing, which I never noticed before. The rendering is really quick after the SP shows up in Profiler. So...I have no clue what the problem could be. Any help would be GREATLY appreciated!
I would just stick with a predicate like:
Where thing in (#Sets)
Where the 'Sets' variable could be from another dataset I created obtained from SQL like:
Select 'Brett' as Name
Union
Select 'Anna'
Union
Select 'John'
Union
Select 'Jenny'
Simple choose to get the data for sets from 'get data from a dataset'. Once the variable is set SQL 2008R2 and higher should do the lifting for you with figuring out the clause of the predicate in expression of Where thing in (#Sets) actually translates to:
Where thing in ('Brett', 'Anna', 'John', 'Jenny')
The primary solution to speeding SSRS reports and decreasing server load is to cache the reports. If one does this (either my preloading the cache at 7:30 am for instance) or caches the reports on-hit, one will find massive gains in load speed.
Please note that I do this daily and professionally and am not simply waxing poetic on SSRS
Caching in SSRS
http://msdn.microsoft.com/en-us/library/ms155927.aspx
Pre-loading the Cache
http://msdn.microsoft.com/en-us/library/ms155876.aspx
If you do not like initial reports taking long and your data is static i.e. a daily general ledger or the like, meaning the data is relatively static over the day, you may increase the cache life-span.
Finally, you may also opt for business managers to instead receive these reports via email subscriptions, which will send them a point in time Excel report which they may find easier and more systematic.
You can also use parameters in SSRS to allow for easy parsing by the user and faster queries. In the query builder, type IN(#SSN) under the Filter column that you wish to parameterize, you will then find it created in the parameter folder just above data sources in the upper left of your BIDS GUI.
[If you do not see the data source section in SSRS, hit CTRL+ALT+D.
See a nearly identical question here: Performance Issuses with SSRS
Create a UDF which will take a comma (or some other delimiter you want to use) separated list, and return a table you can join on.
https://blogs.msdn.microsoft.com/amitjet/2009/12/11/convert-comma-separated-string-to-table-4-different-approaches/
Then you can take set up a parameter in your sproc such as #TheList varchar(max)
You should then be able to use it in a JOIN, Use it to create a temp table and then join on that in your query, or use it as a sub-select.
We use this quite often, and found that if you are primarily using values which are Integers, then the returned table should be a table of INT's to increase performance.
Pseudo example:
declare #TheList varchar(max)
set #TheList = ('1,2,3,4,5,6,7,8')
select *
from dbo.MyRecords r
join dbo.udf_CreateArrayTable(#TheList) at on r.RecID = at.RecID
I have a report working well where I extract the number of logins per user. Each login takes up one row on the report.
I have date parameters and my DB goes back a year. However it seems the report will only show 40/50 rows despite a report expecting to deliver, say, 250 for the amount of times I logged in.
Is there some setting in reporting services that limits the number of rows delivered. Can't find it anywhere..
Thanks.
The answer to your question: nope, as far as I know there's no real equivalent of SQL's TOP 50 statement in SSRS itself.
Some things that come to mind that may be causing your symptoms / can be investigated:
What happens if you run the query for the dataset in SSMS? Be sure to fill in the exact parameters the report's using (if any).
Run the query as a test from SSRS designer. If you're using Visual Studio: right-click the dataset and hit "Query...", then hit the red exclamation mark and fill in any parameters if needed.
Try putting a CountDistinct call (on your dataset) in a textbox somehwere in the report, by itself.
Check the filtering and grouping on your tablixes, perhaps even by looking at the XML source code for the RDL.
Show the parameters in textboxes (oldskool printf debugging! :D) to make sure they're what you expect them to be when the report's run on the Report Server. If they're not: try deleting the report on the server and re-deploying it.
Have a look at the ExecutionLog2 View in the ReportServer database, specifically the Number of Rows returned.
As mentioned in the comments by Atilla: You may also monitor exact SQL SSRS sends to server using SQL Server Profiler.
I'm tasked with reporting on survey data using Reporting Services 2008.
My challenge is this:
a survey has any number of questions
a question is one of three types (a numerical eval, a yes/no question, or a free text)
To handle this, I decided to use subreports on my main report, e.g. I defined one report for each of the three question types, and now when I'm reporting on a survey, I basically dynamically create a RDL for the survey report, using the three question types as subreports.
That actually works quite nicely so far - but I'm facing one major problem: how do I get the data into the subreports?
The approach I see right now is to have each (sub)report per question type define its own data set, based on a shared data source, to extract the values from the database. I'm pretty sure this would work - but I am not very keen on having potentially 5, 10, 20 subreports going off to the database to get their data independently.
What I was hoping for was being able to go fetch the data once for the whole survey, on the "main" report, and then just feed the appropriate subset of data into each subreport, as its being rendered - but I can't seem to find any way to do this....
Am I missing something totally obvious? I haven't had much exposure to Reporting Services, and my last project with it was four years ago (with Reporting Services 2000) - so there's a good chance I am just blind for the obvious solution :-) Please let me know!
Thanks for any hints, pointers to good articles or blogs on Reporting Services, and any help at all!
Marc
The usual way is to pass parameters (like date range) from main report to subreports and then subreports take care of everything else. To improve performance, see if you can render subreports from cache or snapshot. The cache stores report with combination of parameters passed, so after first "database hit" some or most subreports may actually be returned from the cache.
I struggled with the same issue. But there is a way you can achieve reasonable performance using "cached shared dataset". Basically subreports will use larger dataset including all rows for all subreports. By using "dataset filter" each subreport can filter out rows properly.
This is only available for 2008 version however.
If the parameters are the final data you require, then just use them and create a dummy dataset in the subreport - you could just have 'SELECT 1 AS DUMMY' as the sql (this is assuming that the subreports have distinct layouts from one another)
Or perhaps you can rethink the 'master' dataset with a function or table function?
It would still tax the sql server, but at least it would be doing it in one hit and the drain on the RS box would be less.