Sorry for being a newbie to SSRS.
My design goal:
Near term: develop - using SSRS - a simple client side (no reporting server!) report - based on MS SQL data tables, and embed it into the .NET WPF client (application)
Long term: for additional reports, hire external SSRS experts, so they will provide the reports developed, and I will integrate them into the same WPF application.
I managed to do 2 things:
Develop a simple report connecting to MS SQL, using Reports Builder 3.0 - as a result, an RDL file was generated (the file contains all the DB connections)
Embed a ReportViewer WinForms control into the WPF application.
Unfortunately, I wasn't able to load the report I developed, into the application.
I understood from articles on the new that RDL is not designed to support client-side execution (without a server), and RDLC should be used instead. However, I wasn't able to figure out how to conver the report to RDLC, using the Reports Builder - it does not give me an option to save in a different format.
I would appreciate any hint from the experienced people on how to accomplish my goal.
Specifically, should I use RDLC, and if positive - what's the way to get the report in this format?
Thanks
Max
I would recommend using Visual Studio when creating RDLC reports that will be embedded within an application and run in "Local" mode, and using either Microsoft Report Builder or Visual Studio to create RDL reports that will run in "Server" mode within SSRS.
A RDLC report would be created within a WPF Visual Studio project be simply creating a new Report.
A RDL report would be created within a Reports Server project when using Visual Studio.
Alternatively, it appears you could simply rename the file from RDL to RDLC if you don't mind manually correcting the Data Source information in the report definition file: http://msdn.microsoft.com/en-us/library/ms252109(v=vs.120).aspx.
Related
I have an on-promise server and published a sample powerbi report on SSRS, then I called the report inside reportviewer control (in my asp web application), but I am getting below error, can any one please help me with it?
The operation you are attempting on item '/XXXX' is not allowed for
this item type. (rsWrongItemType)،
The Report Viewer Control only suports paginated rdl reports. If you are using SSRS preview with Power BI support the best option for embedding is an iFrame.
I'm trying to create a report in SSRS (Visual Studio 2012) for Dynamics 2011 using fetchXML. I have downloaded and installed the Microsoft Dynamics CRM 2011 Report Authoring Extension (with SQL Server Data Tools support) but I cannot find the Microsoft Dynamics CRM Fetch Type when I try to create a report, please, does any one have any suggestions?
Probably you are trying to create the report in some already existed project, I had the same issue with VS2010 in that case.
To make Fetch XML data source be visible you must create new project in Visual Studio. If all installations were successful, you must be able to create project with Business Intelligence/Report Server Project template, than create new report and in Report Data window (if it not appears automatically - just click on any place on report, go to View menu and find Report Data window) right click on Datasets, than pick "Use a dataset embeded in my report", click "New..." button near Data source drop down and there you should see Microsoft Dynamics CRM Fetch connection type.
Have no possibility to test this with VS2012, hope this will help.
As far as I know the latest version of SQL is SQL 2012 and BIDS for it is done using VS2010. So answer is quite simple - you would not be able to build a report using VS2012, you will have to use VS2010.
You're missing the Report Authoring Extensions. Install these and you'll have the FetchXML in the list.
If you've upgraded to a later CRM version since this post, just search on that version of extension installer instead (2013/2015/2016).
I have an Access db file, and I need to slice and dice the data for various reports that my boss wants.
Is Microsoft Reporting Services a tool that is appropriate for this kind of activity?
If so, would I import the Access data in SQL Server, then the reporting services is a tool that works on SQL Server, allowing the report builder to build custom reports?
SSRS is great for what your trying to do if you wish to stick with Micrsoft tech.
SQL Server Express Adv edition comes with report server. There are plenty of guides out there for install / set up but once going you can use a little application called Report Builder that lets you design the layout of the reports themselves.
Reporting server esentially generates reports from templates you produce in report builder app.
The free edition of report server that comees with SQL Express Adv can export reports into three types, word files, excell or PDFs and does a very good job at it. It also exposes a webservice with a whole myrad of web methods thats very very usefull. ASP.Net also has a control which you can drop into your apps which will render a report.
So in short, yes :)
Hope this helps.
Broad question is: Is there anything Telerik Reporting can do that SSRS (2005) cannot?
Specifics: We're looking to migrate our current Reporting infrastructure from in-house ASP.NET + Crystal (VS Edition) to something else.
Ignoring the cost factor (we have a Telerik license), is there any pros or cons to going with Telerik over SSRS?
Key elements we need are:
generate reports from a custom ASP.NET application
schedule reports
email reports on demand or on a schedule
pdf output, drilldown html
massage the dataset in C# before passing it to the rendering engine
Any experiences or sites that point out advantages or limitations (with either engine) would be greatly appreciated.
SSRS is a server-based reporting system whereas Telerik Reporting is purely an embedded reporting tool. You should compare Telerik Reporting to SSRS ReportViewer control in local processing mode, not the whole SSRS system, unless you intend to use the SSRS server too. I think this is the first question to answer: you should evaluate the pros and cons of using a report server.
The usual reason of choosing embedded reporting is to avoid a server dependency. If you are an application developer and deploy your application to multiple sites, you would have to support multiple SSRS installation in addition to your application. Telerik reports compile to a dll that you can deploy with your application easily.
Generally, server-based SSRS is more feature-rich than Telerik reporting, especially the SSRS 2008 tablix is handy. I think that Telerik Reporting has supported crosstabs only from Q1 2009. It does not support interactive features like drilldown. You should see the known limitations of Telerik reporting and also the substantial improvements in SSRS 2008 compared to SSRS 2005. On the other hand, ReportViewer in local mode understands RDL 2005 only, so you are limited to SSRS 2005 features.
Now, it is easier to look at your requirements.
Generating reports from a custom ASP.NET application
SSRS Server: Microsoft ReportViewer web control configured for remote processing views the reports processed and rendered by an SSRS server
SSRS local mode: Microsoft ReportViewer processes and renders the local RDL 2005 report definitions
Telerik: Telerik ReportViewer processes and renders reports. Reports can be deployed as a single dll with all the resources (images etc.) embedded. This is the strong point of Telerik reporting.
Scheduling reports
SSRS: Server-side feature, not supported in local mode
Telerik : Not supported
Email reports on demand or on a schedule
SSRS : Server-side feature, not supported in local mode
Telerik: Not supported
Pdf output
SSRS: Various output formats in server mode. In local mode, ReportViewer supports only Excel and PDF
Telerik: Various output formats, including pdf
Drilldown html
SSRS Server: Drilldown to a subreport (another RDL report definition) with parameter passing, static urls in report elements
SSRS local mode: Static urls but no interactive features
Telerik: Static urls but no interactive features
Massage the dataset in C# before passing it to the rendering engine
SSRS Server: Supports report datasets defined in RDL, OLEDB compatible
data sources, XML data, Integration Services packages and standard .NET providers
SSRS local mode: This quote is directly from Lachev's book (p.525):
ReportViewer supports two types of
data sources in local processing mode:
a dataset that contains an ADO.NET
DataTable object or an enumerable
collection of business objects.
ReportViewer Windows Forms also
supports binding to instances of
System.Windows.Forms.BindingSource and
to System.Type. Report Viewer Web
server supports binding to an instance
of System.Web.UI.IDataSource.
Telerik: any DataSet or DataView can be set as a datasource at runtime
Given your key elements, and assuming that you are doing internal reporting inside a corporate firewall, I'd definitely recommend using an SSRS server. Try to get one SQL Server 2008 licence or use SQL 2008 Express as a reporting server. But if you absolutely have to use embedded reporting, Telerik is probably a better choice, at least until Microsoft ReportViewer supports RDL 2008 in local mode. This new ReportViewer should be shipped with Visual Studio 2010.
For SSRS, I recommend reading Teo Lachev's Applied Microsoft SQL Server Reporting Services. Sample chapters are available at the book's site the and in Google Books.
Telerik Reporting has excellent support too. Developing Telerik reports relies heavily on samples and support forums.
I have also written blog posts on embedded reporting and Telerik Reporting in particular.
Just adding to mika's reply regarding Telerik interactivity:
Their reporting now offers a few interactivity features, namely navigating to a subreport (drill-through), navigate to a bookmark, and navigate to URL. Their current roadmap mentions that they will add interactive sorting and drill-down by the end of 2011. These should bring their reporting product much closer to SSRS in this regard.
I want to add some new information about Telerik's solution.
Some of the things that were previously not supported, such as Scheduling reports and Email reports on demand or on a schedule are now available as part of the Telerik Report Server product. The Report Server comes with the Report Designer mentioned above. More information about if is available here.
One of the main reasons we stopped using SSRS and went with Telerik is because Telerik has much better support across browsers. Naturally, one would not expect MS to provide equal support for a rival product when it comes to browser compatibility.
Since you are planning one doing a web based application this may be a factor.
I first started using Telerik reporting version 2010 Q2 and never had an issue linking reports over a web app to provide drill-down or linking functionality. It was quite simple and intuitive.
Another thing to think about is that SSRS report files which are RDL files, whereas a Telerik report is compiled into your app. If you need to change your report you'll need to recompile and redeploy your app. For RDL files, you simply upload them to the SSRS server. I still prefer Telerik though, even though it means a slightly longer SDLC for a change request.
Another thing that grinds my noodle is that as long as we used SSRS we had to have both VS 2008 and 2010 installed, because VS 2010 does not have support for designing RDL reports like 2008 has (BIDS is basically a scaled down version of VS 2008: Visual Studio 2010 Reporting Services Projects? )
With Telerik we can stick to using VS 2010.
Comment on "Telerik Reporting has excellent support too. Developing Telerik reports relies heavily on samples and support forums.":
No. You're making an assumption. I have created many complex reports without needing any direction from forums/sample/etc - its a very intuitive tool. I am sure there are many developers out there who have been able to do just fine without "heavy" reliance on the forums/samples - its not rocket science, it's cake.
SSRS Local mode is not supported in Azure.
In the latest versions Telerik Reporting have Report Designer that is tool like Report Builder and the report viewer support XML report definitions (trdx). So no compiling is required if you change the reports.
We have a lot of reports on the Intranet that take parameters. All reports are going to be re-built in SSRS. Our goal is to pass all the parameters to the report from the .net application.
What would be the easiest and the fastes way to render reports from .NET application?
If you are using VisualStudio 2008, you should be able to add the MicrosoftReportViewer control to your toolbox and add it to your form designer that way.
If not, you can add a reference to your project to Microsoft.ReportViewer.WinForms (or .WebForms).
More information is http://msdn.microsoft.com/en-us/library/ms252073(VS.80).aspx under the section marked To add the ReportViewer control to your form