The Reporting Taxonomy guru in my office has requested that during our next TFS upgrade, that the datasources Tfs2010ReportDS and Tfs2010OlapReportDS not be placed right in the root/home folder of the reporting server. He would like all tfs datasources and tfs reports tucked away in their own tfsreports folder. While the reports install nicely in a folder, the datasources appear to have no way to control where they are created. Specifying a folder within the TFS administration console while configuring report appears to affect only reports, not datasources. While I could move the datasources after they are created, I fear that I would break all the reports that depend on the datasource and force me to manually update each one. Because we didn't follow best practices of keeping everything in one team project, this would require that I visit 50+ reports. Am I missing a some setting somewhere that controls where the datasources are created?
P.S. we are recreating all reports as a part of the upgrade using this MSDN article (https://msdn.microsoft.com/en-us/library/dn148128.aspx) and powertools, etc.
This is not supported by TFS and as per the documentation it owns both the instance of RS and SQL and any change to the documented installation and permissions will negate your support agreement with MS (invalidate the warranty).
However you can achieve it if those pushing for this change are willing to take on that support from MS. They will need to manually configure all reports up from, and then continue to manually update the reports when a new team project is created. This procedure may need to be reverted and redone every time you upgrade TFS so they are taking on this task on a quarterly basis.
I would recommend that you NOT do this and explain to them that the instances of RS, AS, and SQL used by TFS are owned and managed by the application itself and that they should keep their grubby paws off of it. 90% of all issues I see in the field (I have been a TFS consultant since 2010) in TFS configuration and upgrade are due to DBA's believing that they know better than the product team.
TFS and all its systems should be a black box managed by your TFS Support team.
We are planning to use SQL Reports in our company and we are currently evaluating the ways to expose the reports to end users. Should we use a reporting web service and then render the reports through a .NET Application? Should we use a report viewer or should we expose the SQL GUI to the users? What are the pros and cons of these over each other? Could anyone please help? I couldn't find any information anywhere for this.
The simplest is to use the Report Manager website that is enabled by default with an SSRS installation it's very quick and easy to get running and the security/ snapshot(cache) / subscription (email etc) options are easy to configure on a per site /per folder /per report basis. It's drawbacks are:
It's ugly - although if you are good with CSS it is possible to mess
with it, but I wouldn't. Newer versions e.g. 2008R2 and 2012 are less ugly
It has an ugly URL - although you could use a DNS alias to get
around that
It doesn't let you control how parameter drop-downs and other
objects appear on the page, but that's minor
I usually use Sharepoint (MOSS not WSS) (if the company has that) with the report viewer web-part. It doesn't require any special Sharepoint SSRS integrated mode - you can read about that but it's that's not a path I recommend taking.
The reports then appear to be embedded within the company's existing intranet site which looks professional IMO. Powerview for sharepoint is also a good option (or performance point in older versions of Sharepoint)
I would definitely NOT go down the road of webservice, that would entail a huge amount of unecessary programming. If you have a lot of spare .NET developers around I still wouldn't do that.
Rather to use the report viewer object in Visual Studio to display a report in an .NET web application. Designing reports using the BIDS (2008R2 and earlier) or SSDT (2012) is much easier than programming, particularly if you've used other reporting tools such as crystal reports or even Access. Using that report viewer object is a much better option than rolling your own.
I've written my response in order of easiness and work required. Hope that is helpful.
I've inherited a live SSRS server and have been asked to amend a lot of reports that are on there.
Is there a quick way I can "export" all of the reports/data sources to a local instance so I can develop against it using BIDS?
e.g. Can I copy the ReportServer database from Production?
What else would I need to do?
I'd like to be able to have a Development copy of everything, with DataSources pointing to copies of the production databases but with the same names. Therefore I could re-write the report and re-define any SP's required locally, and then just deploy the new RDL to the server along with the ALTER SP scripts.
Is that possible or even sensible!?
Personally, with the volume you mentioned in the comments (30 RDL's and 3 databases) I wouldn't recommend some automated cloning of the entire Reporting setup from production to local. Instead, I'd suggest the following:
Reports
Go to the web front-end for your reportserver (typically http://yourserver/reports). Find each report, open it, and on the Properties tab click the Edit button. This button does not do what you might expect (edit the report inside the browser), but instead offers you a download of the RDL file. Save all the RDL files in one folder on disk.
With 30 reports manually downloading the reports may take you maybe an hour, max. This will probably beat most automated approaches. And since you should only need to do this step once...
Databases
It's not entirely clear from the question, but if you only have production databases and no DTAP setup yet, now may be a good time to start with that. You could host clones of the 3 production databases on a test server or possibly on your dev environment. Note that the schema's important here (should be the same as production), the data doesn't have to be entirely up to date.
Alternatively you can skip this bit and develop your reports against the production databases, assuming you can create connections from your dev machine to the production databases. Up to you.
Visual Studio / BIDS
This bit has a few parts to it:
Create a new reports project and solution in Visual Studio.
Add the existing RDL files you've downloaded earlier.
Depending on how the reports were set up, you may need to add shared data sources in your project, to get your reports up and running.
After all this, you should be able to preview your reports from Visual Studio (either with data coming from the "cloned" databases, or directly from production).
At this point you should also be able to safely make changes and preview/test them before deploying them.
Be sure to add the solution, reports, etc. to your version control system of choice.
Deployment
Once you've made changes you want to deploy to the reportserver, you have two basic options:
Deploy them using BIDS (see also the deployment properties MSDN page)
Go back to the web front-end, find the report, open the Properties tab again, click the Update button. This allows you to re-upload the RDL file with the changes you've made.
From now on you can just rinse and repeat on making updates and deploying the reports. No need for cloning/exporting the entire SSRS instance to keep things in sync.
I have been studying SSRS 2005 / 2008 in the past weeks and have created some server side reports. For some application, a colleague suggested that I look into RDLC for that particular situation. I am now trying to get my head around the main difference between RDL and RDLC.
Searching for this information yields fragmented information at best. I have learned that:
RDLC reports do not store information about how to get data.
RDLC reports can be executed directly by the ReportViewer control.
But I still don't fully understand the relation between the RDLC file and the other related systems (the Reporting Server, the source database, the client).
In order to get a good grasp on RDLC files, I would like to know how their use differs from RDL files and in what situation one would choose RDLC over RDL. Links to resources are also welcome.
Update:
A thread on the ASP.NET forums discusses this same issue. From it, I have gained some better understanding on the issue.
A feature of RDLC is that it can be run completely client-side in the ReportViewer control.
This removes the need for a Reporting Services instance, and even removes the need for any database connection whatsoever, but:
It adds the requirement that the data that is needed in the report has to be provided manually.
Whether this is an advantage or a disadvantage depends on the particular application.
In my application, an instance of Reporting Services is available anyway and the required data for the reports can easily be pulled from a database. Is there any reason left for me to consider RDLC, or should I simply stick with RDL?
From my experience there are few things to think about both things:
I. RDL reports are HOSTED reports generally. This means you need to implement SSRS Server. They are a built in extension of Visual Studio from SQL Server for the reporting language. When you install SSRS you should have an add on called 'Business Intelligence Development Studio' which is much easier to work with the reports than without it.
R eport
D efinition
L angauge
Benefits of RDL reports:
You can host the reports in an environment that has services running for you on them.
You can configure security on an item or inheriting level to handle security as a standalone concept
You can configure the service to send out emails(provided you have an SMTP server you have access to) and save files on schedules
You have a database generally called 'ReportServer' you can query for info on the reports once published.
You can access these reports still through 'ReportViewer' in a client application written in ASP.NET, WPF (with a winform control bleh!), or Winforms in .NET using 'ProcessingMode.Remote'.
You can set parameters a user can see and use to gain more flexibility.
You can configure parts of a report to be used for connection strings as 'Data Sources' as well as a sql query, xml, or other datasets as a 'Dataset'. These parts and others can be stored and configured to cache data on a regular basis.
You can write .NET proxy classes of the services http:// /ReportServer/ReportingService2010 or /ReportExecution2005. You can then make up your OWN methods in .NET for emailing, saving, or manipulating SSRS data from the service directly of a Server hosting SSRS reports in code.
Programmatically Export SSRS report from sharepoint using ReportService2010.asmx
Downsides:
SSRS is kind of wonkey compared to other things on getting it up fast. Most people get confused by the security policy and designing reports as an 'add on' to VS. SQL 2005 = VS BIDS 2005 , SQL 2008 = VS BIDS 2008, SQL 2012 = VS BIDS 2010(LOL).
Continuing on 1 the policy for security settings IMHO are idiotically overcomplex. There is server security, database security and roles, two security settings on the page hosted for the service. Most people only set up an admin than can't get in and wonder why other users cannot. Most common complaint or question on SSRS is related to getting in generally from my experience.
You can use 'expressions' that will supposeduly 'enhance' your report. Often times you do more than a few and your report goes to a crawl in performance.
You have a set amount of things you can do and export to. SSRS has no hover over reporting I know of without a javascript hack.
Speed and performance can take a hit as the stupid SSRS config recycles the system and a first report can take a while at times just loading the site. You can get around this by altering it but I have found making a keep alive service for it works better.
II. RDLC reports are CLIENT CONTAINED reports that are NOT HOSTED ANYWHERE. The extra c in the name means 'Client'. Generally this is an extension of the RDL language meant for use only in Visual Studio Client Applications. It exists in Visual Studio when you add a 'reporting' item.
Benefits of RDLC reports:
You can hookup a wcf service much much much more easier to the dataset.
You have more control over the dataset and can use POCO classes filled with Entity framework objects or ADO.NET directly as well as tables themselves. You can monkey with the data for optimization it before binding it to the report.
You can customize the look more with add on's directly in code behind.
Downsides:
You need to handle parameters on your own and while you can implement wrapper methods to help the legwork is a little more than expected and unfortunate.
The user cannot SEE the parameters in a 'ReportViewer' control unless it is in remote mode and accessing an RLD report. Thus you need to make textboxes, dropdowns, radio buttons on your own outside the control to pass to it. Some people like this added control, I do not personally.
Anything you want to do with servicing the reports for distribution you need to build yourself. Emailing, subscriptions, saving. Sorry you need to build that in .NET or else implement a proxy that already does that from above you could just be getting using hosted reports.
Honestly I like both for different purposes. If I want something to go out to analysts that they use all the time and tweak for graphs, charts, drill downs and exports to Excel I use RDL and just have SSRS's site do all the legwork of handling the email distributions. If I want an application that has a report section and I know that application is its own module with rules and governance I use an RDLC and having the parameters be smaller and be driven by the decisions the user made before getting to the report part of what client they are on and site and then they usually just choose a time frame or type and nothing more. So generally a complex report I would use RDL and for something simple I would use RDLC IMHO.
Q: What is the difference between RDL and RDLC formats?
A: RDL files are created by the SQL
Server 2005 version of Report
Designer. RDLC files are created by
the Visual Studio 2008 version of
Report Designer.
RDL and RDLC formats have the same XML
schema. However, in RDLC files, some
values (such as query text) are
allowed to be empty, which means that
they are not immediately ready to be
published to a Report Server. The
missing values can be entered by
opening the RDLC file using the SQL
Server 2005 version of Report
Designer. (You have to rename .rdlc to
.rdl first.)
RDL files are fully compatible with
the ReportViewer control runtime.
However, RDL files do not contain some
information that the design-time of
the ReportViewer control depends on
for automatically generating
data-binding code. By manually binding
data, RDL files can be used in the
ReportViewer control. New! See also
the RDL Viewer sample program.
Note that the ReportViewer control
does not contain any logic for
connecting to databases or executing
queries. By separating out such logic,
the ReportViewer has been made
compatible with all data sources,
including non-database data sources.
However this means that when an RDL
file is used by the ReportViewer
control, the SQL related information
in the RDL file is simply ignored by
the control. It is the host
application's responsibility to
connect to databases, execute queries
and supply data to the ReportViewer
control in the form of ADO.NET
DataTables.
http://www.gotreportviewer.com/
I have always thought the different between RDL and RDLC is that RDL are used for SQL Server Reporting Services and RDLC are used in Visual Studio for client side reporting. The implemenation and editor are almost identical. RDL stands for Report Defintion Language and RDLC Report Definition Language Client-side.
I hope that helps.
From my experience, if you need high performance (this does depend slightly on your client specs) on large reports, go with rdlc. Additionally, rdlc reports give you a very full range of control over your data, you may be able to save yourself wasted database trips, etc. by using client side reports. On the project I'm currently working on, a critical report requires about 2 minutes to render on the server side, and pretty much takes out whichever reporting server it hits for that time. Switching it to client side rendering, we see performance much closer to 20-40 seconds with no load on the report server and less bandwidth used because only the datasets are being downloaded.
Your mileage may vary, and I find rdlc's add development and maintenance complexity, especially when your report has been designed as a server side report.
Some of these points have been addressed above, but here's my 2-cents for VS2008 environment.
RDL (Remote reports): Much better development experience, more flexibility if you need to use some advanced features like scheduling, ad-hoc reporting, etc...
RDLC (Local reports): Better control over the data before sending it to the report (easier to validate or manipulate the data prior to sending it to the report). Much easier deployment, no need for an instance of Reporting Services.
One HUGE caveat with local reports is a known memory leak that can severely affect performance if your clients will be running numerous large reports. This is supposed to be addressed with the new VS2010 version of the report viewer.
In my case, since we have an instance of Reporting Services available, I develop new reports as RDLs and then convert them to local reports (which is easy) and deploy them as local reports.
If you have a reporting services infrastructure available to you, use it. You will find RDL development to be a bit more pleasant. You can preview the report, easily setup parameters, etc.
While I currently lean toward RDL because it seems more flexible and easier to manage, RDLC has an advantage in that it seems to simplify your licensing. Because RDLC doesn’t need a Reporting Services instance, you won't need a Reporting Services License to use it.
I’m not sure if this still applies with the newer versions of SQL Server, but at one time if you chose to put the SQL Server Database and Reporting Services instances on two separate machines, you were required to have two separate SQL Server licenses:
http://social.msdn.microsoft.com/forums/en-US/sqlgetstarted/thread/82dd5acd-9427-4f64-aea6-511f09aac406/
You can Bing for other similar blogs and posts regarding Reporting Services licensing.
For VS2008, I believe RDL gives you better editing features than RDLC. For example, I can change the Bold on a selected amount of text in a textbox with RDL, while in RDLC it's is not possible.
RDL: abcd efgh ijklmnop
RDLC: abcd efgh ijklmnop -or- abcd efgh ijklmnop (are your only options)
This is because RDLC is using a earlier namespace/formatting from 2005, while RDL is using 2008. This however will change with VS2010
If we have fewer number of reports which are less complex and consumed by asp.net web pages.
It's better to go with rdlc,reason is we can avoid maintaing reports on RS instance.
but we have to fetch the data from DB manually and bind it to rdlc.
Cons:designing rdlc in visual studio is little difficult compared to SSrs designer.
Pro:Maintenance is easy.
while exporting the report from we page,observed that performance gain compared to server side reports.
if you want to use report in asp.net then use .rdl
if you want to use /view in report builder / report server then use .rdlc
just by converting format manually it works
I'm looking to implement SQL Server Reporting Services as our standard reporting platform in our company. We were trialing Crystal Reports, but alas it seems to be plagued by issues.
SQL Server Reporting Services looks to be a great product, but I have a concern or two.
I have some existing web apps in ColdFusion, and the backend is in MySQL. If I move forward with SQL Server Reporting Services, how should I set up my environment? Is there a JDBC connector or is ODBC the only way to talk to this?
How does it integrate for the user? Will I need to re-authenticate the user to view the reports? Will I need to put a link in ColdFusion to link to the Reporting Services system? Is there a way to make it seamless for the user?
Should I port all the backend to SQL Server to fully leverage the SQL Server platform? Should I convert my existing apps to ASP.NET, and make the entire platform SQL Server / ASP.NET?
It's not too bad in the fact that the existing apps / MySQL aren't of a size that is too big to port. So I guess just looking for some best practice advise to see if its okay to use the reporting services component on its own, or if I'm much better to consolidate everything into a Microsoft solution.
I think it'll be easier than you think!
Reporting Services will happily pull reports from any OLEDB or ODBC source, and MySQL has ODBC drivers, so there's no problem getting at your data through an SSRS report.
You can set up the authentication in a number of ways. If your users are already authenticated in your Windows domain, this will be easier:
SSRS needs to know who is viewing the report. It will allow anonymous viewing (if you enable it; it's off by default), but if you're using IE and are logged in to the same domain as the IIS server, it's completely transparent
SSRS can then use this identity to connect to the data source, or it can use another identity. This is configurable per report or per data source.
One thing you could do is embed your reports within iframes in your coldfusion pages. This would make the whole thing seamless. The reports are accessible by sending an appropriately formed URL to the server, so it's quite flexible.
As for changing everything to ASP.NET, you'll really only get benefits from that if you ever need to write (and integrate with) your own code to manage the reporting server, or write custom extensions (data providers, delivery extensions and the like), but in my experience this is so rare as to be not worth considering. Go with what you have for now.