Related
I am building an application and the client is asking for reports. Normally we would create the reports for them using reporting services. We are wanting to give the client report builder and let them build there own reports. Some of these reports can be complex and I am not 100% sure how far report builder will take us.
Before we decide if it’s worth giving the client report builder. What are the limitations of report builder? What type of report is it no good for?
I found it is fine for creating and managing reports to be placed on the report server. You obviously cannot use it for .rdlc reports. For most standard users and power users it will be just fine and do what they need, and will not require the entire VS IDE shell that comes with SQL Server (BIDS).
Just remember, if the client is asking to manage their own reports, it's kind of an "all or nothing" situation. You cannot limit their access to the data. Make sure they have a read only reporting account set up on the server. Any reports you create for them originally are backed up.
Train up time may vary depending on the technical level of the end-user expected to use the tool.
The company I work for is looking for a reporting solution with the following requirements:
Must be able to generate a set of reports nightly.
Must give the client the ability to create reports dynamically.
Must have robust export features.
Must have a viewer that can be displayed within a web application.
The company is looking at utilizing Crystal Reports and/or SSRS. Our company is mainly .NET developers using VS2k8 and SQL Server 2k8.
What are some of your experiences with each product and which one do you think would meet our requirements? It seems both products offer the requirements I mentioned, but they both feel robust in different areas.
If you plan on using .net and sql server why bother with Crystal Reports? It is definately the wrong route to take. Take advantage of Reporting Services as it is very very very easy to use, setup, and deploy.
The web placeholder for hte reports has automatic export to excel, pdf, rtf, html, etc.
It is very robust and a very clean intuitive tool. The use of stored procedures within datasets makes it all the better.
We initially went the CR route and it was nothing but trouble and not as easy to build and deploy simple reports. We moved to RS and it is night and day...
From my own personal experience, SSRS is much simpler to set up and use - it also seems to be the way MS are going. In addition to that, if you're already using MS SQL server, you have no further license costs.
I haven't used the SSRS report builder heavily, but it certainly allows the creation of relatively simple reports by (somewhat skilled) end users.
EDIT: Should note that my personal experience of crystal reports has been akin to repeatedly shooting myself in the foot...
One downside to both Crystal Reports and SSRS is that report-viewer controls have COM dependencies. Moreover, much of the BusinessObjects .Net SDK has COM dependencies. Probably not a big deal if you plan to host the site internally, but worth mentioning.
I had a client whose hosting division wouldn't allow for COM installations on the shared server. Fortunately, I was able to use the BusinessObjects WebServices SDK in combination with BusinessObjects OpenDocument URL SDK to build a custom interface to BusinessObjects Enterprise.
Hope this helps.
Crystal and Reporting Services are both similarly capable tools despite what people say. Each tool can do most of what the other can with each one having particular areas in which it excels.
However, rather than installing Crystal you can try installing Reporting Services and just set fire to piles upon piles of used bank notes - the end result will be the same.
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 after a tool to generate decent-looking documents from templates, that needs to:
be invoked through code (not interactively)
run on Windows, ideally invoked from code within a web-server
process standalone* report files that contain their own internal data definitions, query options, etc (i.e. ideally so that we can push simple report files to the server, and it simply work - where report/document maintenance is not necessarily a developer activity)
access data from a database (SQL Server 2005) based on parameters (ids etc) that we pass in
export (again, through code) to pdf or similar
*= where standalone simply means that the report is fully self-describing; it is fully expected that additional reporting runtime components will be required to execute the report. Contrast to rdlc which uses the data-sets from the local VS project.
I looked at the rdl/rdlc options (Visual Studio 2008), but rdlc seems to be coupled to the assembly (not standalone), and rdl seems to lack the code-based export ability. The version of Crystal Reports included in VS2008 seems very similar to rdlc - presumably the full Crystal Reports offering has more functionality, but has a non-trivial price tag too...
I'd welcome any suggestions for an appropriate, professional looking tool that might be suitable and recommended...
I think SQL Reporting Services fully support all of your requirements.
I have build some sophisticated solutions myself with SSRS.
(Example)
Fully manageable through code (via SSRS WS) (Upload, execute and export Reports)
Used SQL Server as database
Queries are defined in RDL (or Stored Proc) and based on parameters
There are other solutions like Telerik Reporting or Data Dynamics ActiveReport, but they are not free.
Let me know if you need more informations
SSRS WS: With that I mean the Web Service Interface (Report Server Web Service
). There is also a URL Access method, but I don't think it's a solution for you
I dont think you can satisfy all requirements. Number 3 especially is the killer.
On one reading, I see it as adhoc reporting generating it's on SQL. On another, it is giving users "empowerment" to do roll their own within some limits you define?
You may have looked already... but have you thought about using the ReportBuilder functionality to set up the basics and leave users to do the rest? You'll need a report monkey at some point anyway to set soemthing up.
Edit, after comment:
Reporting Services it is then.
It comprises a web service that renders RDL files uploaded from VS.
Report Builder is a template for users to hack and bash their own within the limits and environment you set.
Architecture of RS 2008
Our Data Dynamics Reports product sound like it is for you. It is a fully programmable reporting component for .NET / Visual Studio. View the documentation on the API here. You can export the reports to any of our various formats, including PDF, HTML, and Excel and it also includes an end user designer control that you can embed into your own applications to let end users modify or create their own reports.
The reports are stored in RDL - the same XML dialect that Reporting Services uses - in fact you can take any existing RDL files and open them in Data Dynamics Reports. In addition to compatibility with RDL, we add many more features, such as "themes" to consistently style your report, master reports (think ASP.NET master pages for reports), and several other built in controls such as a calendar, barcode, and dashboard controls to name a few.
Now lets look at your requirements one-by-one and see how Data Dynamics Reports might solve them:
be invoked through code (not interactively) - Data Dynamics Reports includes comprehensive API.
run on Windows, ideally invoked from code within a web-server - You can use Data Dynamics Reports in client-based, or ASP.NET applications, it even support medium trust ASP.NET applications (webservices are fine).
process standalone* report files that contain their own internal data definitions, query options, etc (i.e. ideally so that we can push simple report files to the server, and it simply work - where report/document maintenance is not necessarily a developer activity) - Data Dynamics Reports uses standard RDL (not rdlc) which includes all information bout how to retrieve data from your datasource. We also include an end user designer control to allow you to emebed a design environment for these standalone files into your own applications.
access data from a database (SQL Server 2005) based on parameters (ids etc) that we pass in - Data Dynamics Reports includes comprehensive support for parameters (even get the "valid values" from a query.
export (again, through code) to pdf or similar - Data Dynamics Reports supports exporting to PDF, HTML, Excel, Word, images, and XML.
I hope it works out for you, and let me know if you have any additional questions.
Scott Willeke
Data Dynamics / GrapeCity inc.
I think, based on all the criteria, you likely need to look at Crystal Reports, since you want the reports to be standalone, although, you could also create a report designer out of XtraReports or ActiveReports Pro and have much of the same functionality.
As for running it on the fly and having it generate, distribute, and archive the reports that run, check out our product at www.versareports.com. It should work with any .NET report designer you want to use and provides the enterprise-class report server framework you likely need.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Which of Crystal Reports and SSRS (SQL Server Reporting Services) is better to use?
On the one-hand, Crystal Reports is a steaming pile of expensive and overhyped donkey poo, and on the other hand SSRS actually fulfils all the promises that CR marketing makes - and it's free.
My contempt for CR stems from many years of being obliged to use the horrible thing. There's really no point in detailing the utter odiousness of CR when I can give you references like Clubbing the Crystal Dodo or Crystal Reports Sucks Donkey Dork (not as funny but rather more literate and substantiated with technical details).
Free?! Yup. You don't even have to buy MS SQL Server to get it - you can install SQL Express with Advanced Services. This is available as a download that includes SQL Server Reporting Services. While SQL Express is limited in the number of concurrent users it can support, the following observations are salient:
The licence for SSRS obtained as
part of SQL Express only requires
that it be deployed as part of SQL
Express. There is nothing forbidding
connection to other data sources or
requiring that a report obtain data
from SQL Server.
The abovementioned version of SSRS
has no intrinsic restrictions on
user connections. All limitations
are imposed on the SQL Express
database engine.
SSRS uses ADO.NET, which includes,
out of the box, drivers for Oracle,
Jet (Access), OLEDB and ODBC
Thus you can connect the free version of SSRS to any back-end to which you can connect ADO.NET, which includes (for example) MySQL. I am told by Rory in a comment below that this is "not supported". That's true but I can't find anything in the licence that forbids it and while the drivers are not supplied by SSExpress they certainly are supplied by most versions of Visual Studio and you can ship them in your setup kit. This may not be an expressly supported configuration but so what? Even if you did have a full MSSQL licence it would be asking a bit much to expect Microsoft to help you talk to some third party database (not to mention a bit weird).
I use SSRS extensively at work both for inward facing reports and for outward facing reports embedded in ASP.NET applications that provide bureau services to large numbers of paying customers. In our case it happens that the backing store is a licensed copy of Microsoft SQL Server 2008, but this is incidental to the technical merits of our reporting solution.
There is a long list of capabilities that Crystal Reports claims to support but which either don't work or which require a staggeringly expensive licence if you want more than five users. You can't even trust CR to do SQL correctly. SELECT COUNT(*) FROM SOMETABLE WHERE 1=0 should produce a result of zero but it it produces one. The built-in query engine is defective, and a team that screws up something a bunch of amateurs can do for free (eg MySQL) has no hope of getting anything you'd describe as performance out of their code.
And they don't. The evil thing leaks memory like a bucket with no bottom, and if you use SQL profiling tools you will find it is spectacularly inefficient.
As for the alleged support, I can personally attest that dialog resize bugs have gone uncorrected for decades after they were first publicly documented. If you get out your credit card and pay the extortionate ransoms demanded (I too would want handsome pay to support such a horror) you will find yourself talking to someone who claims his name is David, but inexplicably pronounces it "Dah-feet", and who doesn't even understand your question, much less have an answer.
The SSRS support situation is fairly similar, but it actually works so you don't really need much.
SSRS, on the other hand, does everything that CR claims to. It is not without bugs, but they are delightfully few, and they seldom survive more than one release cycle.
The SSRS designer UI is hosted within the Visual Studio IDE. It is attractively presented in typical Microsoft style, but more than this it is quite well thought out, incorporating several simple but fundamental departures from traditional report designers. For example, to present tabular data you define a table rather than fiddling about with individual text boxes. As a result you don't have to screw around trying to line them up, and putting borders on them is a trivial stylesheet exercise.
SSRS actually does all the things CR claims to, it's inexpensive, there is extensive reliable technical documentation, it's designed to be extended (also documented) and you can connect it to anything for which you can get an ODBC driver. This is a no brainer.
Some shortcomings of SSRS
It is not obvious how to bind fields in page headers and footers.
It is not possible (so far as I know) to position relative to the bottom of a page. This is a genuine problem for certain types of report, and one for which I can think of no workaround.
There's no support for expando horizontal rollups in cross-tabulations.
There's no direct support for report headers and footers. Use Rectangle objects at top and bottom of the report layout, with pagebreaking properties set appropriately. Or use subreports. The people who complain about this obviously haven't tried very hard.
Lack of support for overlapping group intervals (the CR grouping system can do this) UPDATE SSRS 2008 R2 now supports this. It's buried in the grouping edit dialog. Look up "group variables" and read this.
It actually looks like overlapping groups can be done with SSRS2005 too, although I never knew that. I wonder did anyone ever crack the bottom-relative positioning issue?
I've been using Crystal report till version 10 and was always doing stuff i wanted successfully along with ASP.NET applications. Its output on web is really good like WYSIWYG and exports to Excel and PDF are also accurate. Printing is also marvellously correct.
Recently, i've been working on SSRS 2005 for around an year and have been living to witness so many lackings that must have been provided out-of-the-box too. SSRS web output varies greatly with different browsers and diff resolutions and would easily make a developer sick. Moreover, the scrolling issues with report viewer would make an end-user mad quite early as it is based on HTML using an IFRAME. (Note: Crystal 13 uses an IFRAME in the web-viewer which suffers from sporadic text-wrapping and overlapping issues). The exports are not good at all. You cannot align images left or center in cells and cannot specify background colors for images. You cannot center align complete report body. For possibility, i've played with the rendered HTML for hours and figured out exact replacements to make that works, but these simple fixes were not known to SSRS developers i guess because probably, they never used SSRS for themselves.
Further, in web applications, you need to bear the bad UI for parameters out-of-the-box. I have simply removed it completely and the cost of creating it in ASPX pages made me think to design tabular reports in DataGrids instead using ObjectDataSource and database pagination technique. You cannot layout the parameters to your needs. Bugs in paramters sections postsback complete reports without any changes. Paging with grouping works with a trick, but than sorting fails on complete dataset. For every bit of medium to advanced level of UI requirement, SSRS costs so much of time figuring out that it is simply not possible. As there are less of SSRS users, online community has no good solutions for simple problems. Not to forget the good side of SSRS is its deployment, notifications built-in, caching and configuration side, but no UI to win.
BOTTOMLINE is that i've seen SSRS frustating you just due to the nonresponsiveness of Microsoft Support team when they have to say 'sorry! not now' after a month. SSRS 2008 also doesn't have many of these issues fixed rightaway. Moreover, moving to SSRS' 08 means a complete migration of back-end platforms as well. Keeping the equation in mind that the more you use a software, the more it gets mature over time, Crystal is anyways a much better choice because, SSRS soon accumulates costs for fixing their bugs by yourselve.
You can deploy an app using Reporting Services by including 3 DLL files. That's a huge benefit. (Note--you have to get one of the 3 DLL files from the GAC.)
With Crystal Reports, you have to install the runtime on each machine that will run the application (either a website or client app).
Reporting Services has all of the features most people need, and the deployment is MUCH easier. I will never user Crystal Reports unless I have to.
Since this thread has popped back open, I'll add my two cents. I had to use Crystal for about three years during the version 7 and 8 days. I hated every minute of it. I've seen a little bit of the newer versions and still don't like it.
I dislike it so much that it pains me to say this: from my experience Crystal's better suited than SSRS for complex reports. A coworker and I tried desperately to get a moderately complex report layout to work in SSRS and gave up. My impression of the product -- just my opinion, mind you -- is that it's not quite ready for prime time.
Crystal will make you hate your life and look for another job, but there's a reason it's so pervasive: it works.
Reporting Services is much better in my experience. It is a better environment, but best of all the connections (data sources) are separate from the report and can be shared. This makes for much simpler deployment between environments.
I've used both, I'll add a couple of points to what's already been said:
For simple stuff, I'd recommend SSRS by default. Crystal is a bit bloated and quirky.
Crystal can easily export to MS Word format (.doc). Customers want this pretty often in my experience.
If formatting is important, Crystal may be better. For example, SSRS reports can't have more than one type of text in a single text box. Meaning that you can't have, say, a comment at the top of the report that has both italics and normal text. Crystal can do this:
Note: This report contains data from start date to end date inclusive of those dates.
SRSS can't (without multiple overlapping textboxes). I once had a 20 page word document given to me, to be converted to a report with data for the dozen or so graphs and tables in it. I started out in SSRS, but realised that in Crystal I could just copy and paste the hardcoded bits of the report straight from word, with coloured headings and all, and saved days of work. So Crystal does have a better "designer" in many respects.
Update:
Apparently both of these issues have been fixed in the current SRSS. Anyone care to comment further on this?
I agree with #Carlton partly for the reasons he describes. I also think that reporting services is a more mature product (even though Crystal Reports has been around longer). The Test and deploy model is pretty hearty, and the built-in ability to track report usage is very helpful.
I also find it much easier to design reports in Reporting Services - Microsoft has learned how to build a good IDE, whereas the Crystal IDE has always seemed like an after thought (though that's better than an afterbirth, which is what it used to be).
Edit: Additional thoughts
I also think that in a Windows shop, SSRS offers all kinds of sweet integrations with the OS and SQL Server. You can rely on SQL assemblies for built-in code reuse fairly easily in SSRS, and the integration with the Active Directory security model makes securing your reports very easy.
Man...my company has sooo many crystal reports...and the company before that had lots too. From version 8.5 to 11.5. They kind of already have their foot in the door so to speak. I think the CrystalReportViewer is a steaming piece of crap but it does work(for the most part).
After reading some of these answers, I'm switching to SSRS for my next reporting project! The writing is on the wall...MS will drop Crystal from VS and replace with SSRS. The only thing that's going to suck is when MS starts charging for it.
EDIT: Messing around with SSRS today and it looks quite promising. I must say the designer is taking some getting used to...CR Designer has it beat in ease of use. You can tell this is designed for programmers where as CR is geared toward report designers.
EDIT2: SSRS really fails to meet my reporting needs. Designing reports sucks when you want to preview and no parameter prompting available for standalone. Is there a better way to design them...preferably not in VS?
Did you think about an alternative? If you want to use the features of Crystal Reports but don't want to pay so much for it you could have a look at Crystal-Clear which is an Java based reporting tool supporting Crystal Reports templates too. It comes with a GUI-designer and data sources are also configurable per system. (Almost ODBC-like, you just set a name for the connection and the connection is configured on the system.)
I wonder why no-one mentioned one big issue with CR - that it just fails in source control or team environment. Correct me if I am wrong but I really looked very hard for any report diff tools. There's one (released about year ago) but it just doesn't do well - not because it's bad but (I guess) because CR just don't expose report structure correctly or something... I tried to export .rpt to XML but it's clunky and wrong. I even tried to write my own .rpt comparer.
It's not about team development only; even if there's single developer it's a nightmare to maintain reports versions, and if your customer decided to add few things or to change few colors, you're now cursed to track every single textbox since there's absolutely no way to find out the changes.
RDL format is much more clean and open. And this can be a pretty major advantage.
I have used both for years.
Crystal reports charges way too much and I try to use SSRS whenever possible.
However, SSRS does not support firefox or any other browser, only IE, this is a problem.
The reports in Crystal look nicer and the exports are more powerful, users want good exporting to Word.
If you are a java programmer, I would use Jasper Reports, it is free and uses Java language for functions.
I've used both (Crystal Reports 2008 and SSRS 2008) because I did not notice this thread in time.
Apart from the setup which was a bit easier with CR, I could not notice a single feature where CR is at least on par with SSRS. Yes, Crystal Reports is really that bad.
In my opinion the absoultely worst part in CR is the IDE. But there are also other killer features, such as poor SQL performance and horribly looking graphs (at least in the CR version that comes with VS 2008) are also notable "killer" features.
I have worked with both CR and SSRS and this what i found.
Crystal Reports runs in its own memory while SSRS runs in the limited SQL Server memory.
Crystal report is way too expensive. Recently they have slashed their price to 250$ i think as a response to SSRS 2008 release.
SSRS is free.
The biggest reason why Crystal report thrives :
You can design 80% of reports in a project using SSRS. But for the remaining 20% you have to use some other reporting tool. These 20% reports are used by none other than top level managers , directors & CEO. Their requirement can never be undermined and CR does a wonderfull job there.
Crystal report is still COM based. which is a pain in the a**.
Crystal report is not lacking capabilities or features. It is the work horse of SAP. But lot of its classes are protected and dont provide access to programmers. This is by intention. The SAP people are so greedy they want to keep every feature under control and charge extra fortune for exposing the claases and objects to the developers under special license arrangement. Just debug and quick watch the ReportDocument object in VS you will know inspite of everything available in the object you can hardly use them in your code !!
As far as GUI & CSS issues are concerned expecting a COM object which is designed for precision printing , to render correctly in every browser is a moot point as even a simple div renders differently in different browsers.
I have been working with Crystal reports since 7 years and cursing it all the time while actively exploring all other alternatives. But i am yet to come across something as flexible as Cystal Report. For bulk of the work SSRS is good. But for Dashboards , Complex Reports with subreports, Balance sheets, trial balances i shall never waste my time in SSRS.
Just try a Google Trend search on Crystal Report. It has been steadily declining since last 6 years. surely the future does not look good for CR.
But Hey ! MS, SAP and ORACLE still endorse Crystal Report at the core of their applications !! and no BI product comes cheap.
I feel like a martian having an extensive and positive (but sometimes complex) experience with Crystal Reports, which is now completely integrated in our user interface (VBA), where requested reports parameters and filters are transparently inherited from the user interface ...
If you're considering SSRS and are concerned about the fact that it's "free" but you need to either buy and additional SQL Server license or distribute SQL Express, then you might be interested in Data Dynamics Reports
It offers all that is in SSRS and adds Master Reports, Themes, Calendar data region, Data Visualization (Databar, Sparkline, Iconset, ColorScale, ...), complete object model for maximum programming flexibility, royalty free end user report designer, barcode report item, excel template export and data merging, and much more. You can download a trial from Data Dynamics (now GrapeCity) and try it with few reports, you will not be disappointed.
I've worked with both now and have seen them side by side. Crystal has been good, but expensice over the years. Its clunky, but we've gron accustomed to it and familiar with the interface. I don't work in the LAMP environment, This house works with MS Dynamics and MAS with some pretty large clients.
I love not having to worry about the client install for SSRS. Distributions is far easier and sharing data sources and report models is working out well.
AS far as broweser go, I've seen perfectly rendered SSRS 2008 gauges in Firefox. I have exported those gauges to Excel without issue. I have deployed reports with and without MOSS to phones. The ability to use windows authentication to deploy reports as well as hide them is fantastic. The report viewer object in VS 2005 and later is sweet.
People, please refer to version of which you are talking about!
For example, the VS2008 built-in free RDLC reporting (the same as SQL Server 2005 Reporting Services) doesn't support binding fields in header and footer, and it is a basic feature!
Now I'm converting a huge report from this VS2008 Reporting / RDLC 2005 to Crystal Report 2008 Basic (which comes with VS2008) because it doesn't have this basic feature.
I am confident that Reporting Services 2.0 / RDLC 2008 (which comes with Visual Studio 2010) and better yet, the newest Reporting Services 3.0 / RDLC 2010 (which comes for FREE in SQL Server 2008 R2 Express With Advanced Services) are better SSRS solutions.
SQL Server R2 Express with Advanced Services (FREE)
http://www.microsoft.com/express/Database/InstallOptions.aspx
Right now I am making a Proof of Concept for Reporting Services 3.0 / RDLC 2010, and will post the results.
Reporting Services (SSRS/RDLC) is always more easy to work, but easy comes with a price. For simple reports, always choose SSRS/RDLC. For complex reports with master-detail, page control and so on, please make a PoC of these scenarios with newest SSRS/RDLC versions (2008,2010) and also with Crystal Reports.
For those who are comparing the old Crystal Reports XI and Reporting Service 1.0 please see this 2005 post:
SQL Server Reporting Services and Crystal Reports: A Competitive Analysis
http://www.crystalreportsbook.com/SSRSandCR_Conclusion.asp