I'm trying to setup a process whereby data subscriptions can be created via a stored procedure rather than through the report manager. We are planning to migrate hundreds and hundred of reports over from my old system eventually and the current data subscription model seems to have a lot of limitations.
I've done extensive googling and haven't found anyone that has actually done it themselves. I did come across an article where the subscription is created and then a procedure is used to call that subscription but this seems to be a bit of a hassle.
Has anyone managed to create a procedure that creates the data subscription and job to send out the reports?
If you have to migrate a lot of subscriptions to another system, have a look at a tool called RSScripter. With this you can easily copy reports over to another system.
To answer your question, the web services api is a better option to add subscriptions. I'm not aware this has been done via a procedure, it's certainly possible but probably unsupported and complicated.
I have been in a similar situation than what i think is yours (a lot of subscriptions, need to add/remove them automatically). I ended up completely skipping subscriptions and writing https://busyreports.codeplex.com. You can certainly use subscriptions but for me it was too many hacks needed.
You can create an internal application to manage this process via the ssrs api, however, there are existing third party applications that can do this.
If you would like to create a dynamic recipient list for emailed reports then you can do this by using a data driven subscription with the To: field being pulled from a stored procedure that returns a list of emails.
You can also look at the CreateTimeBasedSubscriptionSchedule stored procedure in the ssrs ReportServer database.
Related
I managed to create a typical SSRS report by building one through MSSQL BI development environment. I used a simple procedure to retrieve a list of databases that reside on our SQL servers. My question would be...would SSRS allow me to build a native UI app in displaying SQL procedure results in a more user friendly way?
For instance, I am currently manually running procedures to retrieve information about our backend systems, and I wonder whether SSRS would be an ideal tool to automate the process by allowing a user to view the information that the procedures produce in a more user friendly way?
I'm not 100% sure about your question, when you ask (emphasis mine):
would SSRS allow me to build a native UI app in displaying SQL procedure results
In any case, SSRS isn't meant for nor very good at functioning as an "App" with proper UI/UX. If you're just after basic features for letting the user pick a stored procedure and then reporting the results back to the user SSRS may suit your needs.
You continue:
I wonder whether SSRS would be an ideal tool to automate the process by allowing a user to view the information that the procedures produce in a more user friendly way?
Whether it's "ideal" really depends on your context.
Finally, the last bit is somewhat confusing: "more" than what? Running queries directly in SSMS? Then probably yes.
Bottom line: if you stick with using SSRS for reporting purposes (possibly interactive, to a certain degree), then SSRS may be the ideal tool for your case.
Is it possible to distribute reports based on a database insert trigger, using the standard edition of SQL Server 2008 R2? The trigger will be looking for a certain column to have a certain value, which will indicate that it is time to fire off a report. This will not happen very often, probably a couple of times a day.
This must be a common scenario, and yet I can't find any information on it, which must mean that I'm asking the wrong question. (I am completely new to SQL Server.)
TSQL using FireEvent?
Thanks,
Mike
Is there any aversion to checking for the value in the application, then execute and deliver the report from there using the report execution webservice? I don't like the idea of database triggers kicking off external processes. Too many clunky configuration dependencies and opportunities for failure for my taste.
If you really want to pursue this, this seems to be least complicated way (it requires reporting services and application database to on same instance):
Create reporting services subscription that delivers report in desired format
Open the SQL Server agent job list and get the unique identifier of the job name that corresponds to the subscription that was created (you'll have to look at job creation and last/next run datetime to find which job relates to your subscription)
Create trigger that executes the msdb.dbo.sp_start_job procedure, passing the job name that matches your subscription
See what I mean about clunky dependencies? I would definitely stick with checking values and delivering the report in the application layer if at all possible.
The reason you do not want to use a trigger for this is that you will not be able to insert/update/delete if reporting is down.
Can you have some slack time (5 minutes or so)? If so do a trigger to send to a differnt table that the change was made and have a job to look at that table for the change every five minutes.
I've been requested to implement a means of reporting on add/update/deletes on files stored sharepoint (MOSS 2007). After a little bit of research I found out sharepoint has out of the box document auditing which I enabled a couple days ago. I ran the report today, but excel spreadsheet was not very easy to look at.
Also I'm not positive of this, but I believe only site collection administrators can generate thsi audit report, and I dont really want to give the people who want these reports that much permission.
I'm curious what are some alternatives or recommendations? Should I try and get this information off the sQL Server and display it in reporting services, or perhaps try and build a include it in a dashboard?
Thanks
If you have access to the SSRS instance for SharePoint, you can get the report file. You can then make a copy and edit for the report you would like. permissions are a separate issue that can be tackled however you desire, especially if you create a copy and store as a new report.
We are designing a system where we intend to use reporting services for reporting.
The users will be able to create their own reports.
But, there is a requirement to log all access to data.
Anyone have an idea of how to do this? For example is it possible to store a PDF copy of every report that a user runs?
Edit
One way to solve this would be to read the data using a stored procedure, anyone know if this is possible with reporting servcies?
There's a solution here on codeplex that allows you to monitor which reports have been run Execution log importer
I would like to use SQL Reporting Services 2008 to generate my reports, but I want to use my own UI for specifying the report type, columns, parameters and everything. I want to be able to take these criteria, and then kick off an asynchronous request to SSRS and have the report emailed to me. Is this possible? I don't want to go all the way down the road of researching SQL Reporting Services 2008 only to find that it doesn't do what I need it to do. Also, I will have a ton of DB partitions that the data will need to be pulled from. Some reports will need to pull data from only one of these, but other ones may actually need to span different databases. Is it possible when sending a report request to SSRS to specify what servername/database to pull the data from? Is it possible to tell it to take the data from multiple databases and combine it? Thanks.
Like Crystal Reports, ActiveReports and other report generators, SSRS has two basic elements behind each report: the SQL query and the report layout. No matter what tool you use for the SQL -- it can be inline SQL in the report or a call to a stored procedure -- it's going to be the same query. Multiple databases are fine as long as you can specify them up front.
You can have parameterized queries, so the user is prompted to input the relevant filters (customer ID, product group, date range, whatever).
Doing the report layout is similar to other tools -- you drag and drop controls like labels onto the report, and set their formatting.
SSRS does provide a lot of options for distributing the report, including email. You can embed the report in an ASP.Net web page, leave it on the report server site for users to browse to, run it in the wee hours of the morning and cache it so every user doesn't have to wait for the lengthy query to run.
It's a great tool. I think it will be worth your effort to experiment with it. I would wait on creating the customized UI until you've exhausted the possibilities inherent in the tool.
SSRS is not designed with this scenario in mind, for that matter I am not sure that any out of the box reporting solution is going to have an elegant solution for this. While SSRS can do what you are asking (as well as others), it is by no means quick or easy. You seem to be looking for an advanced ad-hoc solution with dynamic sourcing of the data. I would first question the requirements and determine if the business scenario really justifies such an implementation. I would weigh custom building a solution vs your learning curve with a BI reporting solution. You may find that it is easier to just build something on your own.
I think the heterogeneous dynamic database mashup is probably going to be the most challenging part.
Depending on what your scalability requirements are, one place that has that part covered, and a report writer, is Access. (Duck! Incoming!)
I think you may be creating a rod for your own back to a certain extent as RS ships with a few interfaces for report creation.
Mind you the end product is an rdl file which is nothing but xml, so you can write them by hand if you really like.
Multiple data sources are supported, but combining them on a single control/chart/etc are not, so you'll need to configure yourself a cross database capability from one of your data-sources prior to the report request if you want to do that.