Comparing to SSRS

[hchattaway]

Hello
I am new to examing these controls, but love what I see! The endorsement by margus Eggar sold me.

I have not seen the comparison between your reporting tool and SQL Server reporting services... how do these compare? What does yours offer over SSRS? I love your grid control and wil be buying it next week.

Thanks
harold

[Vassil Petev]

Hi Harold,

Thank you for your interest in our reporting tool. Regretfully, the first version of our product will not be able to match the functionality of Microsoft Reporting Services 2005, for obvious reasons. Nevertheless, version 2 (expected at the end of the year) will be much more powerful and will provide more functionality, in our opinion, then Microsoft Reporting Services 2005.

Nevertheless, here are a couple of things we believe v1 is superior than SSRS:

• Programmability - in our tool, the report items are .NET objects and expose a number of events that allow users to interfere in the report processing/rendering. Events add additional level of report customization. We also offer simple and intuitive API. With SSRS you can create user functions to be called from a property expression only (in VB).
• Styling -  we offer advanced ccs-like cascading styles. You can attach a style to the top-most report item - the Report that defines the font, colors, text alignment that will apply to all the report items and define the general appearance of the report. Then for a particular item you can specify additional style to make it look different from the rest of the report. The resultant item style will be combination of its own style and the styles of its parent items. The benefits of the cascading styles is the easy customization of the appearance of large number of items; you can reuse one set of styles for different reports and make them look the same way; or you can create several different sets of styles and when you apply one of the sets to a report, you can make it look differently without the need to change the report itself. SSRS does not offer such granular styling capabilities.
• Stylesheets - we have them in v1, but there are not present in Microsoft Reporting Services
• SSRS depends tightly on IIS and MS SQL Server whilst the telerik Reporting solution doesn't require neither IIS nor MS SQL Server to deploy and process the reports.

What we lack:

• wizards
• export to Word, RTF, TEXT/CSV, XML, Excel 2007, Word 2007
• Bookmarks, Hyperlinks, Drilldown reports, Drilltrough reports, Recursive relationships
• Aggregate functions and totals, Property Expressions
• Table, BarCode, Crosstab, List/repeater

I hope this helps.

 
Greetings,
Rob
the telerik team

www.telerik.com | dnn.telerik.com | www.sitefinity.com

[ScottR]

Rob,

Thanks for the comparison. I think we're going to stick to SSRS for now, but I would like to see your intended features for v2. I assume those will be posted in your "roadmap" on May 31st?

Also, I gather from your post that the telerik report engine runs on the web server during the normal page life-cycle. Is that correct?

From reading another thread it appears that the entire report is sent to the client (all pages) and the viewer handles everthing client-side. If the entire report is generated during the normal page lifecycle and sent to the client, how well does this scale? SSRS uses web services to retrieve individual pages from the report server one at a time, which seems to be pretty nice for larger reports. Once telerik implements drill-down, I assume there will need to be some postbacks and partial report rendering.

[ernie racer]

..it appears that the entire report is sent to the client (all pages) and the viewer handles everthing client-side..

i don't think so..

daniel

[ScottR]

i don't think so..

daniel

In another thread the question was asked whether the report viewer used AJAX. The response was that the report viewer did not use AJAX because it didn't do any postbacks.

AFAIK, you'd need postbacks to dynamically load pages for viewing. Unless they don't consider AJAX calls "postbacks", but then the answer to the question should have been "Yes, the report viewer uses AJAX calls".

[ernie racer]

as far as i can analyze that (my knowledge is limited when it comes to javascript) they are using an iframe which gets the "report content" from changing and invoking the src-attribute with javascript * (without using the XMLHttpRequest object of the browser!) which gets the data from an HttpHandler [as you can see in your web.config: <add path="Telerik.ReportViewer.axd" verb="*" type="Telerik.ReportViewer.WebForms.HttpHandler, Telerik.ReportViewer.WebForms, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a9d7983dfcc261be" validate="true"/>]. the report viewer gets the data on the server side only one time with the first request, since you can disconnect from your database (in my case sql server) and still browse through the reports. so i suppose the report data or the pre-generated content - depending what telerik decided to use - is sittin' in the session state on the server and waitin' ... or it's temporarily written as a file on the server harddisk and waitin' there (what i don't think).

telerik, feel free to correct me.

anyways, some pages (like wikipedia.org) consider this approach as ajax, too.

daniel


*
ReportViewer.prototype.NavigateToPage = function(pageIndex)

{
var input = document.getElementById(this.currentPageID);
input.value = pageIndex;
var url = this.baseReportUrl + "&PageIndex=" + pageIndex;
this.BeginWait();
var reportFrame = document.getElementById(this.reportFrameID);
reportFrame.src = url;
};

[Chavdar]

Hi all.

Daniel, your analysis is completely correct. We are using an iframe in the report viewer to display the report. This is a common way to achieve this functionality. Generally speaking, the iframe can also be considered as an AJAX implementation for the old days when the XMLHttpRequest object was not supported by all browsers. For viewing the reports we think that this approach is the most suitable as it avoids problems with page lifecycle, viewstate, browser memory leaks, etc.

The requested report page (one at a time) is served by an HttpHandler which uses the processed report from the Session state. The report is processed (bind report, calculate pages) only once - during the first request.


All the best,
Chavdar
the telerik team

Instantly find answers to your questions at the new Telerik Support Center

[Nick Devore]

This feels like a 50/50 question to me: 50% reasonable and 50% "Why would you want that", but here it is anyway.

Is there a way to preview the whole report in the web browser?  The page by page view in the browser is fine if that's what you want.  But what if you want all three pages displayed in the browser?

[ernie racer]

from my point of view it sounds like a good idea, also for a different reason than yours:
i don't really remember if it worked in one of the beta versions, but if you have for example a report with more pages than one, it seems like the print button would do the job only for one (the current) page, which i think is really ... not the best idea. maybe it's just an error in the final product and can be fixed - which would be really nice!. i also understand that this might be not the best thing to do (for the client, the browser, and for the server), if you have a report with hundreds of pages, but: i don't know that (yet) and that decision has to be made i think by the developer - meaning us - (-> i.e. 50 pages or more [i don't know with how many pages the browser gets hurt]) - we could just disable the print button and allow only pdf export for a later printing. whatever, if it's not an error from my side, then i'm sure you will come up with some nice ideas. if it can't be done at all, then let the user generate larger reports - besides nick's reason - and the printer can take care of that...

daniel

ps: by the way, i forgot: the ShowPrintButton property is set to false by default in the final version and some people might think that there is no button like that  :-)

[Svetoslav]

Hi guys,

The problems with preview/print the whole report in the web viewer are similar -- if you have a large report with a lot of data the generated HTML will grow a lot and will take a lot of time to be sent to the client browser. So we've chosen to page the reports always. The size of a report page is calculated roughly from the preset page size and the sections' sizes. However, you can always set a custom page size larger enough for all the sections to have the whole report rendered on 1 page.

Printing from the web viewer is based on the browser's printing functionality - this means that the browser controls how to page and print its content and the we cannot manage it in no way. Moreover the HTML is not physical page oriented format like PDF or TIFF that are much more suitable for printing. This is the reason to hide the print button by default.

Regards,
Svetoslav
the telerik team

Instantly find answers to your questions at the new Telerik Support Center

[rh]

I can guarantee you that my users are going to want to run a report and then hit the print button to print the entire report. Is my understanding correct that this is not currently possible?

[Svetoslav]

Hi rh,

Precise printing from the web browser is a must, so we'll do our best to add this feature for the next release scheduled for the end of the year. Unfortunately, time will not permit us to do it for the upcoming Q2 2007, due next month.

 
Sincerely yours,
Svetoslav
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

[Durlabh Jain]

The way I have handled the printing problem in my applications is by showing the report as a PDF. Usually people have PDF viewer such as Adobe Acrobat or Foxit to open the PDF in the browser itself. This way, they see all the default controls of the PDF viewer including Print button and they are happy with this.

I hope that this will provide you a viable solution before Telerik comes with something integrated in their web report viewer.

[Vassil Petev]

Hello,

We are happy to announce that Reporting Q3 2010 offers drill down interactive functionality for all report items, but charting (a workaround for charting is posted here). Q3 2010 was released yesterday.

The drill down interactivity complements the previous interactive features, introduced earlier this year (drill through, links, etc.). Review What's New in Q3 2010 Reporting and check the more technical Q3 release notes.

The Q3 version with drill down reporting is available for download in your account.

Enjoy and send us your feedback!


Sincerely yours,
Vassil
the Telerik team