Forum Discussion
Parameters Missing
Yes, but the SSRS report is based upon a data set that has all of the data loaded into it either via the actual transactions themselves or the ETL function that loads up all of the data. This is exactly equivalent to the data model in Power BI.
When the user in SSRS selects parameters, the SSRS report is essentially building a query to query the database and return the relevant rows. This is analogous in Power BI to the use of slicers.
In review. Your database behind your SSRS report has all of those "useless rows" in it because it needs to have them in order for the SSRS report to query it to return the relevant rows for the visualizations. Power BI data model also needs all of those useless rows in its dataset in order to return relevant rows for its visualizations.
What it sounds like what you really want is Direct Query which avoids the whole import process that you do not seem to like. But, I believe in one of the multiple, multiple, multiple threads that you have posted on this topic that you don't like Direct Query either.
There are a number of very useful purposes for parameters. One, for example is the use of parameters to move between development, qa and production environments. So, for example, you parameterize the SQL Server name and then it is very easy to move from one SQL Server to another.
That is just one example. It sounds like parameters are not useful in your case as you are looking for user-based ETL control, which, I would point out, isn't available in things like SSRS either really.
Smoupre,
I have to disagree,
We have hundreds of reports that require user input before the report even loads. Users must choose dates, departments etc... before the data even loads in SSRS. Then, Only the required data is queried and returned. It Blows circles around Power BI as far as speed and flexibility. SSRS reports are 10 x faster , much more user friendly and everyone is in control of the data they load.
In Power BI, I must load millions of useless rows for every user, then only after millions of rows are imported can the user begin to filter data. This is completely backwards and makes no sense to people that have been developing reports for years.
With SSRS, the user sets the parameters they want, then the data loads in lightnening speed as it doesnt require a bunch of useless rows be included in the dataset.
Here is a screen shot of SSRS parameters being used to query SQL data. Users enter parameters and then the data loads according to those parameters.
Yes, but the SSRS report is based upon a data set that has all of the data loaded into it either via the actual transactions themselves or the ETL function that loads up all of the data. This is exactly equivalent to the data model in Power BI.
When the user in SSRS selects parameters, the SSRS report is essentially building a query to query the database and return the relevant rows. This is analogous in Power BI to the use of slicers.
In review. Your database behind your SSRS report has all of those "useless rows" in it because it needs to have them in order for the SSRS report to query it to return the relevant rows for the visualizations. Power BI data model also needs all of those useless rows in its dataset in order to return relevant rows for its visualizations.
What it sounds like what you really want is Direct Query which avoids the whole import process that you do not seem to like. But, I believe in one of the multiple, multiple, multiple threads that you have posted on this topic that you don't like Direct Query either.
Hmmm, Maybee the speed difference then is the fact that all the SSRS reports are On-Premise. I didnt realize that all the data was loading in the back end. I just figured that the parameters were being passed to the SQL query and then the dataset would load.
We cant use Direct Query becouse it is too limited. Every time I have attempted to use direct query except for the most basic of reports , I run accross some un-supported function. Especially when working with Financial Data.
I am going to ignore Parameters for now as thats not a solution. I am going to try and re-model my data so that I can find a way to stop the contsant 5 minute wait when selecting a filter.
What I have noticed is that the lookup function in Dax is lightnening fast compared to creating relationships. If I use Lookup functions rather than relating the data I am getting at least a 120% increase in Power BI report speeds and in some cases even better.
I was hoping to use parameters to limit the amount of data being loaded, but that is also not an option.
Perhaps the best way to do this is create a single fact table, then use Lookup functions for all the other related data.
If SSRS and Power BI are doing the same exact thing, then Parameters are not needed in Power BI.
Thanks for the explenation and help! Back to the drawing board for me...:(
