Sometimes you want to connect to a report server instance using Management Studio, for example to create a new security role or modify an existing one. Recently I tried to log into our newly installed Power BI Report Server (March 2018 edition). I was greeted with the following error:
The Reporting Services instance could not be found.
Read on to see how to solve this problem.
Regularly I have reports that have an extensive amount of columns.
Because the amount of columns, reports tend to become inefficient and have too much information we don’t always need. The users may want to select certain columns and to make the report easier to read.
Hiding and showing columns in SSRS reports using parameters is a solution to make reports more dynamic and easier to use.
At the time of writing of this article, SQL Server Reporting Services did not yet have the possibility to use checkbox parameters. Instead we will be using a multi-value text parameter to show or hide our columns.
Click through to see how to do this.
Using the privileges of R language to enrich your data, your statistical analysis or visualization is a simple task to get more out of your reports.
The best practice to embed R code into SSRS report is to create stored procedure and output the results to report. To demonstrate this, we will create two reports; one that will take two input parameters and the second one to demonstrate the usage of R visualization.
It’s nice to be able to use R to create nice visuals and then import them in your SSRS report, and Tomaz shows how.
If you’re using Kerberos authentication with Reporting Services you’ll at least have to update the rsReportServer.config file with the correct authentication mode. Beyond that you have SPNs on your SSRS domain Service account to consider. This may be managed by your domain administrators but it’s still a good plan to back these up or check that someone is backing these up. It is too easy to clear SPNs or constrained delegation settings accidentally.
Having a backup will also give you a good reference point for building new environments. You can of course easily see SPNs from the command line using this command:
SETSPN –L DOMAIN\SERVICEACCOUNT
What this boils down to is, if you lost your Reporting Services installation today, could you get things back to the way they were?
The SSRS 2017 installation media was easy to find and download from Microsoft. When I ran it, the installation process was simple. There were very few choices to make, and none of them were terribly important or impactful. Other than clicking “Next” buttons, the only choices and input required was to choose the SSRS Edition (or enter a product key), check the box to accept license terms, and choose an installation path (if you don’t want the default). It was so easy, it almost feels like a waste of time to post the screen shots. But since I have them, here they are:
Click through for a block of screenshots and more install info. As for Dave’s question as the end, I think the only way you can have two versions of SSRS 2017 on the same instance is if you have Reporting Services and Power BI Report Server, and they’ll show up in Reporting Services Configuration Manager as SSRS and PBIRS, respectively.
This blog post is around the situation where you have SSRS setup to use HTTPS and thus using a certificate and the certificate expires (or just needs replacing). We had caught the initial error via our Continuous Monitoring of the SSRS site — basically when the certificate expired we got an exception and alerted on it.
The client installed a new certificate but the issue arose where in Reporting Service Configuration Manager we went to use the new certificate but when we chose it we got this error:
“We are unable to create the certificate binding”
Read on to see how to get past this.
So, what have we learned? Well, for one, this is a crappy situation born of poor in-product support. I should be able to configure Solution-level shared Data Sources, use them in as many Projects (within said Solution) as I want, and have VS configuration management support them; bonus points for doing so with saved & encrypted credentials. Ideally, when we check this into source-control, we’d check in the “DEV” environment flavor connection-configs. Then, when the reports get deployed to the “PROD” SSRS server, the same globally shared Data Sources are already present (and they don’t get over-written, thankfully by default!), configured by the DBA with prod credentials, and nobody in the development pipeline needs to know said credentials. Yay?
Not exactly a ringing endorsement.
Wolfgang Strasser covers Power BI Report Server’s scheduled data refresh ability in a two-part series. First, he shows how to configure scheduled data refresh:
What needs to be added here is the fact that data refresh can be speeded up to 1 minute refresh intervals. (Which is much more often compared to 8 times for powerbi.com PRO users).
When you are done with the schedule configuration, save it and the definition dialog is updated with the plan information. The last data refresh timestamp plus the last status is also displayed.
Just like Reporting Services, data refresh happens via SQL Agent job. Wolfgang then shows us what’s in the Power BI Report Server’s metadata database:
CAUTION: The PBIRS meta-database is a system database needed for successfully running PBIRS. Do NOT modify objects in that database – a non-functioning PBIRS could be the result!
The table dbo.SubscriptionHistory contains the history of data refresh actions. A SELECT on this table provides you with the following information:
Subscription metadata (SubscriptionID plus Type)
Execution runtime information (HistoryID, StartTime, EndTime, Status plus Message)
I’m pretty jazzed about this feature.
This post shows how you can generate optimized multi-value DAX parameters in SSRS and achieve greater performance compared to the DAX PathContains function. This will be a short post that provides the SSRS expression to convert multiple SSRS parameters into a double-pipe delimited string for use in a DAX query. In other words, the goal is to use the DAX OR operator (||) instead of the PathContains function. I’m assuming the reader has experience with SSRS, so not all steps will be shown.
Read on for the example, which ended up being a 16X performance improvement.
And the online documentation for the API is here:
Interestingly, the new API seems to be OData compliant – which means you can browse it in Power BI/Get&Transform/Power Query and build your own reports from it. For example in Power BI Desktop I can browse the API of the SSRS instance installed on my local machine by entering the following URL:
This is something that SSRS has been missing for a long time. I’m glad they’re introducing a real API.