Reporting Services Project Gymnastics

Nate Johnson had a bad experience with Visual Studio-based SQL Server Reporting Services projects:

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.

Related Posts

Executing R Scripts In SSRS

Tomaz Kastrun shows how to include R scripts (and visuals) in SQL Server Reporting Services: 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 […]

Read More

Documenting Reporting Services Installations

Craig Porteous explains the types of things you should document in SQL Server Reporting Services: 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 […]

Read More

1 Comment

  • Nate on 2017-12-04

    To be fair, it’s not all bad, and it’s still better than using Report Builder w/ no source-control. It’s just frustrating to not have native multi-project-shared Data Sources support. =)

Comments are closed


December 2017
« Nov Jan »