Re: SQL Server report scheduling

2011-03-15 Thread Greg Kennedy
Hi Greg,
I could be wrong but I don't think you needed the Enterprise version to get
subscriptions. Standard edition is enough and is significantly cheaper.

Greg

On Wed, Mar 16, 2011 at 8:04 AM, Greg Keogh g...@mira.net wrote:

  Folks, our customer needs a facility to generate reports via calendar
 schedules and then distribute them to lists of email recipients.  For
 example, on the first of each month, monthly summary reports with filtering
 arguments for different customers and departments would be generated and
 each would be emailed to one or more related people. They currently do this
 by hand and it's a growing burden on the staff.



 One of us discovered that SQL Server with Reporting 
 Serviceshttp://msdn.microsoft.com/en-us/library/ms159106.aspx(SSRS) seems 
 to do everything we need, so we upgraded to SQL Server Express
 with Advanced Tools (and reporting) and ran some experiments to make RDL
 server-side reports and use the web interface to publish and generate them.
 This all works, and we got excited, but then discovered that subscription
 reports http://msdn.microsoft.com/en-us/library/ms155911(v=sql.90).aspxare 
 not a part of SQL Express editions, so we don't get the facility to
 schedule and distribute reports unless our customer upgrades to the SQL
 Server Enterprise edition which is about $27000 per processor.



 So we have to tell the customer to buy SQL Server Enterprise and we learn
 how to use SSRS, or we find some other way of creating the
 subscription/schedule facility. Our current preference is for the latter if
 there is a way of programmatically generating the RDL reports stored on the
 server. If we can generate the reports, then we're quite happy to wrap it in
 a scheduler (NCron, Quartz .NET, etc) and it's easy to send email
 attachments. That way, SQL Server holds all the report definitions and data,
 and our code schedules and distributes the reports.



 Does anyone know if there is an API or service into SSRS to allow us to
 generate the RDL reports?



 Any other general comments on this matter would be welcome.



 Cheers,

 Greg



RE: SQL Server report scheduling

2011-03-15 Thread Greg Low (GregLow.com)
Officially it's required for data-driven subscriptions but not for standard
subscriptions. However, there are ways around it:
http://sqlblog.com/blogs/greg_low/archive/2008/08/13/data-driven-subscriptio
ns-in-sql-server-2005-standard-edition.aspx

 

Regards,

 

Greg

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Greg Kennedy
Sent: Wednesday, 16 March 2011 8:31 AM
To: ozDotNet
Subject: Re: SQL Server report scheduling

 

Hi Greg,

I could be wrong but I don't think you needed the Enterprise version to get
subscriptions. Standard edition is enough and is significantly cheaper.

 

Greg

On Wed, Mar 16, 2011 at 8:04 AM, Greg Keogh g...@mira.net wrote:

Folks, our customer needs a facility to generate reports via calendar
schedules and then distribute them to lists of email recipients.  For
example, on the first of each month, monthly summary reports with filtering
arguments for different customers and departments would be generated and
each would be emailed to one or more related people. They currently do this
by hand and it's a growing burden on the staff.

 

One of us discovered that SQL Server with Reporting Services
http://msdn.microsoft.com/en-us/library/ms159106.aspx  (SSRS) seems to do
everything we need, so we upgraded to SQL Server Express with Advanced Tools
(and reporting) and ran some experiments to make RDL server-side reports and
use the web interface to publish and generate them. This all works, and we
got excited, but then discovered that subscription reports
http://msdn.microsoft.com/en-us/library/ms155911(v=sql.90).aspx  are not a
part of SQL Express editions, so we don't get the facility to schedule and
distribute reports unless our customer upgrades to the SQL Server Enterprise
edition which is about $27000 per processor.

 

So we have to tell the customer to buy SQL Server Enterprise and we learn
how to use SSRS, or we find some other way of creating the
subscription/schedule facility. Our current preference is for the latter if
there is a way of programmatically generating the RDL reports stored on the
server. If we can generate the reports, then we're quite happy to wrap it in
a scheduler (NCron, Quartz .NET, etc) and it's easy to send email
attachments. That way, SQL Server holds all the report definitions and data,
and our code schedules and distributes the reports.

 

Does anyone know if there is an API or service into SSRS to allow us to
generate the RDL reports?

 

Any other general comments on this matter would be welcome.

 

Cheers,

Greg

 



RE: SQL Server report scheduling

2011-03-15 Thread Greg Keogh
Thanks Greg L, this is very interesting indeed. I've passed your article
link onto the other guys who are more deeply into SQL internals so they can
investigate.

 

I now have to investigate Hoss' hint that I can programmatically invoke SSRS
reports via a web service.

 

I have a 27MB 770 page PDF book titled Applied Microsoft SQL Server 2008
Reporting Services by Teo Lachev. Chapter 15 is titled Reporting for .NET
Clients, so maybe some good news for us will be in there. If I find anything
startling or useful at the end of this research I'll let you all know.

 

Greg K



Re: SQL Server report scheduling

2011-03-15 Thread Hoss Ravanparsa
On Wed, Mar 16, 2011 at 4:19 PM, Greg Keogh g...@mira.net wrote:
 Thanks Greg L, this is very interesting indeed. I've passed your article
 link onto the other guys who are more deeply into SQL internals so they can
 investigate.



 I now have to investigate Hoss' hint that I can programmatically invoke SSRS
 reports via a web service.


Sorry, more info here http://msdn.microsoft.com/en-us/library/ms152787.aspx



 I have a 27MB 770 page PDF book titled Applied Microsoft SQL Server 2008
 Reporting Services by Teo Lachev. Chapter 15 is titled Reporting for .NET
 Clients, so maybe some good news for us will be in there. If I find anything
 startling or useful at the end of this research I'll let you all know.



 Greg K