Is SSRS right for our needs?

I'd really appreciate some help deciding if SQL Server Reporting Services is
right for our needs. We have the following two requirements:
1) Users of our ASP .Net application pull reports from the new ASP .Net
SSRS embedded control.
(Users log in with Forms Authentication)
2) Automated nightly push of emailed reports to thousands of users.
Q1: Does the new ASP .Net embedded control for SSRS work with the
aspnet_users and aspnet_roles tables to identify the current user, display
the list of reports for them and manage security login to SQL Server?
Q2: Can the generation of SSRS report Excel-Output be automated to file
from a nightly SQL Server Job or perhaps from an application that is kicked
off at midnight?
I apologize if this seems a little vague. It's almost as if asking the
question is more difficult than answering it. Ultimately, the question is:
Will SSRS meet our needs for both Pull and Push reports?
Danny LesandriniOn Jul 13, 10:17 am, "dlesandrini" <dataf...@.comcast.net> wrote:
> I'd really appreciate some help deciding if SQL Server Reporting Services is
> right for our needs. We have the following two requirements:
> 1) Users of our ASP .Net application pull reports from the new ASP .Net
> SSRS embedded control.
> (Users log in with Forms Authentication)
> 2) Automated nightly push of emailed reports to thousands of users.
> Q1: Does the new ASP .Net embedded control for SSRS work with the
> aspnet_users and aspnet_roles tables to identify the current user, display
> the list of reports for them and manage security login to SQL Server?
> Q2: Can the generation of SSRS report Excel-Output be automated to file
> from a nightly SQL Server Job or perhaps from an application that is kicked
> off at midnight?
> I apologize if this seems a little vague. It's almost as if asking the
> question is more difficult than answering it. Ultimately, the question is:
> Will SSRS meet our needs for both Pull and Push reports?
> Danny Lesandrini
If I'm following you correctly, in Q1 you are referring to the report
viewer control (which works w/both Crystal Reports and Reporting
Services). The current user is available in SSRS via this expression:
=User!UserID.ToString
As far as I know, controlling access to SQL Server is done via the
datasource set up and controlled via the Report Manager. Otherwise,
controlling report access can only be set via general user security in
the Report Manager. Users can be set up to just browse/view reports,
etc (but no control over which reports, just all). Of course, the
stored procedure/query that sources the report can control whether or
not the user sees the results if the stored procedure accepts an input
parameter that receives the User expression given above.
In regards to Q2, the Report Manager has built in snapshot reporting
and scheduling, etc. The report can be scheduled to execute on a
schedule and exported to Excel.
The main difference between Crystal Reports and Reporting Services is
that the license for SSRS is free w/a SQL Server license on the same
box; however, Crystal Reports requires its own license. So, SSRS is
much cheaper on the budget. Also, Crystal Reports and SSRS have
slightly different export options. SSRS has very convenient report
export scheduling.
Hope this helps in your decision.
Regards,
Enrique Martinez
Sr. Software Consultant