Depending on scenario, we've seen cases where client-side reporting is preferable to doing it on the server-side (offline for example), but it is highly dependent on the use case.

 

the problem with using some other reporting components (devexpress, ...) is that we'll loose quite a bit of the nice features that SQL Server Reporting Services does inherently provide (like easily manageable subscriptions, snapshots, same reports accessible easily through the standard web application front end provided by reporting services etc.)

 

Actually option d) is quite similar to using some 3rd party components for the reporting (which also means loosing the "advanced" features there, but in return it is simple to implement).

 

In a first step we'll go with option d) to provide our customers with reports that they need (based on our object model). In case somebody is looking at the same problem, one can find an easy to follow instruction to use reporting services with the object model at http://codebetter.com/blogs/peter.van.ooijen/archive/2009/07/01/reporting-against-a-domain-model.aspx. The draw back is that it is actually running on the client and not on the server.

 

Andreas

 

 

 

 

 

 

I think you've summarized the options quite well.  I'm tempted to agree with you that options b) and c) will require a more code and maintenance than is worthwhile.  If you need the features of SQL Reporting Services, it may be best just to go straight to the database.  Otherwise, I think a number of the reporting services that can report straight off a .NET object model (Data Dynamics Active Reports, DevExpress, Telerik, ...) will get you the best reuse of your custom business logic.

 

 

what are the best practices for using SQL Reporting Services with DevForce?

 

There are several ways to make use of the Reporting Services and DevForce at the same time.

 

a) Report goes straight to the database, which means that reports and application actually work with a different data model with all the related problems in implementing and maintaining the solution

 

b) Report takes the data from a web service. Which might be similar to a) only that we can actually expose the object model through the web service. But maintainance is still quite a hassle.

 

c) Implementing a data processing extension which provides full support in using reporting services with the data model (but involves quite an investment, but might be the most powerful in the long run)

 

d) Only doing client side reporting and supplying data from the client. Using simpler rdlc's to directly access the data model but actually loosing quite a lot of the the server features.

 

I know some of you are also using DevExpress reporting, but we'd prefer Reporting Services if possible.

 

I am looking forward to exchange some ideas and thoughts on this.

 

Yours

 

Andreas