views:

63

answers:

3

I have an ASP.NET website from which the users themselves will generate custom reports and (possibly) print them. My question is what approach would you recommend (and why):

  1. Generate the report using reporting software like Microsoft Report Viewer or Crystal Reports.
  2. Use simple ASP.NET pages and format the page for printing using CSS.
  3. Generate PDF files using any PDF-generating framework out there and leave the printing to the PDF reader.
  4. Any other choice?

Do note that the user will have selection controls to generate and filter the report accordingly.

Edit: I am using NHibernate as an ORM and connecting to an Oracle database, so SQL Server specific solutions will not work.

Thanks.

+1  A: 

Sql Server Reporting Services.

matt-dot-net
I am using NHibernate as an ORM and connecting to an Oracle database, so SQL Server specific solutions will not work.
Rafael Belliard
I'd second this. Even comes with a simple report builder module that you can expose on the web. It really depends on how complex your reports are going to be, whilst bearing in mind that they're likely to get more complex as time goes on.
Paddy
Reporting Services can connect to Oracle. It is built on SQL Server, but it isn't restricted to SQL data sources to do it's thing!
matt-dot-net
A: 

On past projects I've used both Microsoft Report Viewer and Crystal Reports. They can both output reports as PDFs which you can then serve as a download to the user.

TimS
MRV won't work with Oracle.Crystal Reports looks pretty but will still require code in the querys for this to work. I guess these would be acceptable solutions if the report is fixed, but I don't think these will be very flexible for end-user dynamic reports where all fields aren't necessarily fixed/known/used.
The Mirage
+2  A: 

Just use ASP.NET pages.

We made an app at my previous employer that did a very similar thing. We made a view to relate all the available properties for a given application/program/report. The users had a list to select properties from, and then filtered those properties accordingly. Each property type was a separate object with different filterable properties that the 'manager' could setup for their users.

After selected what columns they wanted to view/filter, the clicked go, we generated SQL and placed 15/30 results at a time back into a paging gridview.

If they wanted to see more than that they could download an Excel CSV export file.

For large, less filtered queries, we restricted the row return count to something reasonable that wouldn't time-out.

It isn't the most elegant, but it was VERY versatile and made almost everyone happy.

To Clarify - this reporting system in and of itself was an app we built (OOP, NHibernate, etc.) to support and simplify this process.

The Mirage
How about the printable aspect? Did you format it using specific CSS @print tags or was that not important to you?
Rafael Belliard
Printing shouldn't be an issue. You can create your own solution based on circumstances, but a CSS solution would work just fine. Also, this isn't a SQL specific solution, as the queries created can relate to any DB through NHibernate or if you are concatenating strings, any DB.
The Mirage
Thanks. I'll be taking this as an example: http://css-tricks.com/examples/EditableInvoice/ :)
Rafael Belliard
Thanks. I'll be taking this as an example: http://css-tricks.com/examples/EditableInvoice/ :)
Rafael Belliard