Thursday, March 22, 2012

Best Practices Question

We have a small inventory database (<1GB). We have a public IIS Server and a
separate box SQL 2005 backend.
I have two ways I can deliver reports to the customer:
1.)create reports on the Reporting Server
2.)create them on the IIS Server locally (.rldc)
In each case I use the ReportViewer component to display them (so I either
connect the ReportViewer to Server Report or to a local .rdlc).
My question is, is it better to create reports on the report server or to do
them in the asp.net project locally -- an rdlc off a dataset?
Note load is very small so server power/capacity for both is not an issue in
this case.
Thank youAs far as executing them not much difference for your situation. However, it
is much easier to create reports for RS rather than local reports if you are
doing anything with subreports, drillthrough etc. You have to write code for
these situations which are handled for you automatically with RS. Also, no
such thing as preview report in development for rdlc. My advice if you go
the rdlc route is to at least develop most of the initial report using the
RS report designer (rather than the designer for rdlc that comes with VS).
Then once it is working (note that you do not need to have a server to
deploy to) rename the report from rdl to rdlc and then add it into your
project at that point.
Note that one thing that is easier with local reports is security, you
handle all that yourself.
--
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"dev648237923" <dev648237923@.noemail.noemail> wrote in message
news:eADLneepGHA.2292@.TK2MSFTNGP05.phx.gbl...
> We have a small inventory database (<1GB). We have a public IIS Server and
> a separate box SQL 2005 backend.
> I have two ways I can deliver reports to the customer:
> 1.)create reports on the Reporting Server
> 2.)create them on the IIS Server locally (.rldc)
> In each case I use the ReportViewer component to display them (so I either
> connect the ReportViewer to Server Report or to a local .rdlc).
> My question is, is it better to create reports on the report server or to
> do them in the asp.net project locally -- an rdlc off a dataset?
> Note load is very small so server power/capacity for both is not an issue
> in this case.
> Thank you
>|||Thanks for Bruce's input,
Hi dev648237923,
I agree with Bruce. As for Local report(rdlc based), it has less
functionality comparing to the server-report(rdl based) supported by the
SQL server reporting service. Actually, local report(rdlc) is a pure .net
framework and Visual Studio 2005 specific solution which is completely
separated from the SQL Server reporting service. In other words, you can
use rdlc report totally without an SQL Server reporting service instance
existing in your environment.(All the rdlc can be created in Visual Studio
and the datasource can be created there, too). While for SSRS report, it
provides many rich support on subreports or drillthrough reports, also the
whole SQL Server reporting services supply us many other features like
custom extensions or some report delivery options. These ones are what we
can not easily do through local report.
For your scenario, I'm wondering whether your report rely heavily on those
SSRS service functionalities. If all of them can be done through client
reports without any difference from server reports. Why not use client
reports, that can make all the work done through Visual Studio without
involving SQL Server reporting service.
Here is a reportviewer Q/A article which mentions many client and server
reports' difference.
#ReportViewer Control in Visual Studio 2005
http://www.gotreportviewer.com/
Please feel free to post here if you have any other concerns or
consideration on this.
Regards,
Steven Cheng
Microsoft MSDN Online Support Lead
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)|||What you and Bruce said worked great -- thnaks for all the great info!
"Steven Cheng[MSFT]" <stcheng@.online.microsoft.com> wrote in message
news:86HUKzjpGHA.1572@.TK2MSFTNGXA01.phx.gbl...
> Thanks for Bruce's input,
> Hi dev648237923,
> I agree with Bruce. As for Local report(rdlc based), it has less
> functionality comparing to the server-report(rdl based) supported by the
> SQL server reporting service. Actually, local report(rdlc) is a pure .net
> framework and Visual Studio 2005 specific solution which is completely
> separated from the SQL Server reporting service. In other words, you can
> use rdlc report totally without an SQL Server reporting service instance
> existing in your environment.(All the rdlc can be created in Visual Studio
> and the datasource can be created there, too). While for SSRS report, it
> provides many rich support on subreports or drillthrough reports, also the
> whole SQL Server reporting services supply us many other features like
> custom extensions or some report delivery options. These ones are what we
> can not easily do through local report.
> For your scenario, I'm wondering whether your report rely heavily on those
> SSRS service functionalities. If all of them can be done through client
> reports without any difference from server reports. Why not use client
> reports, that can make all the work done through Visual Studio without
> involving SQL Server reporting service.
> Here is a reportviewer Q/A article which mentions many client and server
> reports' difference.
> #ReportViewer Control in Visual Studio 2005
> http://www.gotreportviewer.com/
> Please feel free to post here if you have any other concerns or
> consideration on this.
> Regards,
> Steven Cheng
> Microsoft MSDN Online Support Lead
>
> ==================================================> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ==================================================>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> Get Secure! www.microsoft.com/security
> (This posting is provided "AS IS", with no warranties, and confers no
> rights.)
>|||Thanks for the followup,
Glad that those information is of assistance.
Please feel free to post here if there is anything we can help & Have a
nice day!
Regards,
Steven Cheng
Microsoft MSDN Online Support Lead
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

No comments:

Post a Comment