This is a migrated thread and some comments may be shown as answers.

Comparing to SSRS

13 Answers 610 Views
General Discussions
This is a migrated thread and some comments may be shown as answers.
hchattaway
Top achievements
Rank 1
hchattaway asked on 24 Feb 2007, 03:52 PM
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

13 Answers, 1 is accepted

Sort by
0
Vassil Petev
Telerik team
answered on 27 Feb 2007, 01:27 PM
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
0
ScottR
Top achievements
Rank 1
answered on 26 Apr 2007, 07:26 PM
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.
0
ernie racer
Top achievements
Rank 1
answered on 27 Apr 2007, 12:58 AM
..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
0
ScottR
Top achievements
Rank 1
answered on 27 Apr 2007, 05:28 PM
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".
0
ernie racer
Top achievements
Rank 1
answered on 27 Apr 2007, 07:41 PM
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;
};

0
Chavdar
Telerik team
answered on 28 Apr 2007, 10:03 AM
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
0
Nick Devore
Top achievements
Rank 2
answered on 30 Apr 2007, 03:31 PM
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?
0
ernie racer
Top achievements
Rank 1
answered on 01 May 2007, 01:59 AM
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  :-)
0
Svetoslav
Telerik team
answered on 02 May 2007, 09:15 AM
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
0
rh
Top achievements
Rank 1
answered on 24 Aug 2007, 06:11 AM
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?
0
Svetoslav
Telerik team
answered on 24 Aug 2007, 03:38 PM
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
0
Durlabh Jain
Top achievements
Rank 1
answered on 28 Aug 2007, 08:26 PM
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.
0
Vassil Petev
Telerik team
answered on 11 Nov 2010, 10:55 AM
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
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
Tags
General Discussions
Asked by
hchattaway
Top achievements
Rank 1
Answers by
Vassil Petev
Telerik team
ScottR
Top achievements
Rank 1
ernie racer
Top achievements
Rank 1
Chavdar
Telerik team
Nick Devore
Top achievements
Rank 2
Svetoslav
Telerik team
rh
Top achievements
Rank 1
Durlabh Jain
Top achievements
Rank 1
Share this question
or