I have a universe and multiple reports built on top of that universe.
Is it possible to configure that when a certain data subset in universe comes, the certain reports are sent to the end-user (stored on file system in PDF format)?
Basically, the question is - is it possible to create a trigger based on the data that are comming in the universe. This trigger triggers report distribution (not all reports, but only specific ones).
As per my understanding you need to have this reports in some file system in pdf format. am i right? I f so you can schedule the particular report that needs to be distributed.
Regards
Niki
Related
I have 187 reports in a live SSRS/SSAS scenerio. I have a requirement to update the cube all of the reports are feeding from. The requirement is spawned from a change request to one of the reports.
Is there a quick way to determine whether or not I have broken all the other reports based on the new cube design (in short terms, how do I perform automated regression testing?)
Thanks much!
Best thing I can think of is to set up a subscription for every report that goes to an empty folder on a file share, or email if you prefer. If there is less than 187 reports in the folder, then you have a broken report.
You can then create a query of the SSRS database subscriptions table to find the subscription that errored, and which report it was, to go test it further.
If you want to automate the creation of the subscriptions for the reports as well, you could use something like this tool. https://www.2ndrock.com/software/subscriptionmanager/subsmgr.html
I am new to SSRS and I just want to know if it is possible to loop through datasets in an SSRS report and save each dataset separately as an Excel spreadsheet.
For example, if we have a report with 5 managers, if you click on each one of these managers you can see/drill down to all the supervisors that are under this manager and if you click on any of those supervisors you can see all the employees that are under that particular supervisor. Now, what I'm trying to do is I want to save each one of the managers' (and supervisors' eventually) downline in an excel document (although it really can be in any format as long as they can later drill down on it) so that each manager can only get his/her own supervisors/employees. Can this be done in SSRS and if so I'll try to figure out how. Also, if you think there is a better way to restrict every manager from seeing every other manager's supervisors employees please let me know. The report that I currently have is perfect but everyone can see other people's supervisors/employees and their data.
Thanks!!
if you want to generate flat files to send out, then you have to create a parameter on your report, deploy it to the report server, and then create 5 subscriptions to that report.
in each subscription you can set the parameter and where you want to write/email the file.
If the subscriptions part doesn't work well for you (if you have too many to manage), you can use data driven subscriptions (enterprise edition feature), rs.exe scripts (if you figure out how it works), or use my new cool tool (http://busysreports.codeplex.com)
also, you don't have to generate flat files, you can also set up some security so when the managers open the report in reporting services they see only their data.
I'm used to generate reports based on my database tables record and don't have any problem presenting it.
But now, some presentation requirements coming up that seemed to be much complicated to handle if I don't create a dummy table as a repository.
Current System Details and information:
System Type: Inventory Accounting
System design and setup: Can generate reports base on date selected
(transaction date) : Individual Reports for : Balance Sheet (BS),
Income statement(IS) and Cash flow statement (CFS)
New Report requirements:
BS, IS and CFS reports should have different format and display (Mostly the update wanted are the change in Layout display)
Saving of every generated reports
I'm thinking to create a dummy db table because of the 2nd requirement in w/c to save every report generated.
Before, I do create repository table for complicated reports but replaced/erased when another user generates the same report.
Question:
Base on the new report requirements is it really necessary to create dummy table for this type of report requirements?
Well, in real functionality *they can be generated at any time* but for report and recording purposes and as to performance perspective does saving generated reports really make sense?
For those DB Accounting guru, does saving BS, IS and CFS generated reports is a good practice?
Based on the new report requirements, is it really necessary to create a dummy table for this type of report requirements?
Yes, although I would call it a report history table.
Well, in real functionality they can be generated at any time but for report and recording purposes and as to performance perspective does saving generated reports really make sense?
Saving generated reports makes sense from an audit and accountability standpoint. You'd have to ask the people that gave you the requirements, but I've worked on systems where we had to record who made what system queries from what terminal / workstation when. System changes to the database were more strictly monitored. The auditing was required by law.
I've been thinking of the best way to present reports to the end user. We've accumulated several dozen reports. Some are subscription-based and are exported into Excel or emailed out regularly but a large number are run on-demand.
There's the option of sending the users the direct link to the reports. We don't do this because it's not easy to find (they have to dig through emails or bookmark the link)
http://server/ReportServer/Pages/ReportViewer.aspx?myreportrs:Command=Render
We've been embedding reports in sharepoint (or simply adding a link to the report). We're not using Sharepoint Integrated Mode. This has become a little unorganized where we have a large number of links to reports. I'm not sure what other solution exists..
SQL 2008, Sharepoint 2007
Depends on how much maintenance effort and instruction you want to provide. Some likely options include:
Use a SharePoint content page and hardcode a page with links to different reports.
Create a Sharepoint URL list linking to the different reports.
Create an SSRS report that is acts as a central index. This could either be a static page (a report without any data
source, just many static text boxes.) or a dynamic list of reports.
Depending on requirements you could query the SSRS databases and
use that as a central list.
My clients have generally found that a one of these, the Report Manager interface (/reports/), and emailing of specific report urls to be adequate.
Another option I once used: we created a formula (happened to be in Excel) that would create a url with the appropriate custom parameters to return just the data the user was interested in. Passed the parameters to SSRS as part of the URL. (Search on SSRS URL access.)
I am currently working on a MS Access 2003 mdb file. This mdb file will be converted to an mde file before being published.
How do I go about enabling the reports function of MS Access after conversion? Is there a alternative (open source or free software) to the reporting in MS Access? Any suggestions?
Assuming you mean getting users to creat their own reports in the same FE MDE? This isn't possible as you can't open a form or report in design view in an MDE.
We suggest you give the power user a separate MDB linked to BE database. Along with some starter queries and tell them to "have fun". Providing occasional support on queries, explaining, for example, the difference between the joins.
Also I give my clients an Export to Excel button which copies the reports recordset to Excel. I do not attempt to use the report itself into Excel as that generally looks terrible.
Another issue is to consider why users want to create reports. I frequently get clients requesting two different reports on the same data, one with details, one just a summary. You can actually make that a single report and hide the detail section to get the summary report.
Also, many clients consider a report with different data but the same layout to be a different report, and what they really need is the ability to filter the report output according to their needs.
In my experience, both of these take care of 90% of the scenarios where users think they need to create reports.