I need to create an SSRS report that would display space related information for all of our servers and associated databases.
Is there a way to create a stored procedure that would loop through all servers and write space information to a temp table?
Or is it possible to do it via SSRS report where based on parameter chosen, it connects to a specific data source, and gets the space related information?
I need to create an SSRS report that would display space related information for all of our servers and associated databases. Is there a way to create a stored procedure that would loop through all servers and write space information to a temp table?
It would be a bit cumbersome, however you can make use of linked servers and dynamic SQL to loop each server and store results in a base table. You can then use the base table as a datasource for your SSRS report.
A better way to do it would be to use a powershell script to loop through each database server, store the results in your database reporting server and utilize an SSRS datasource to access the records from the reporting server.
Or is it possible to do it via SSRS report where based on parameter chosen, it connects to a specific data source, and gets the space related information?
You can make use of an SSRS dynamic datasource to connect to a specific data source and execute SQL to get space related information - however this would only return capacity information on one server. Here is how to work with dynamic datasources:
http://blog.rdx.com/blog/dba_tips/2014/02/creating-dynamic-data-sources-in-ssrs
Best way to do it as above would be to have a single central reporting server as a central data store, which queries each Database Server and stores the data. You can then point your report to the central datasource
Related
I have a set of 10 reports that we use on multiple instances of our software, currently I create a copy of each report for every database instance.
Is there any way for me to resolve the issue of creating seperate copies, I need just one report set and dynamic datasource switching as per the datasource.
I am expecting a centralized report set that switches as per the instance I am using.
For my company there is a report that ends up in an access database format (.accdb) when it gets to my department. We want to deploy an SSRS with this information. While I was able to do it in Visual Studio the database manager questioned whether this can actually be deployed and work in the server environment. Can this this be achieved?
Are you talking about an Access report, or data inside of Access?
SQL server reports are not built in Access and have absolute nothing to do with Access. The only issue would be then since the report cannot be built in Access, then why attempt to have SQL server open an accDB file for the data source? You would be much better off to simply have Access transfer the table data to SQL server and then continue to use the reports built in SQL server.
So a report in Access has ZERO relationship to SQL server reports. As such, the reports in Access are of no use and if your plan is to use SSRS, then the reports have to be built in SSRS.
It is possible to place an Access accDB data file on the server and have SQL server connect such data, but it generally does not allow or work well with multiple users.
Keep in mind, the reverse is certainly possible and often recommended. You place and keep all data on SQL server tables. You then link the Access application to SQL server. In this setup then the data ALWAYS resides on SQL server, but the reports are in Access. And the general forms etc. built in Access will save + send their data to SQL server (and this works without having to write code).
The above thus suggests that the Access application with the reports has to be distributed to users that need such reports. And such users will thus all share only ONE copy of the data since such data resides on SQL server. And this setup would also allow one to create reports in SSRS without having to upload any kind of data, since the live operating data from the Access application always resides on SQL server.
So in summary:
Access reports are Access reports, just like FoxPro reports are FoxPro reports, and FileMaker reports are FileMaker reports. As such, these reports cannot be used, viewed, or utilized by SQL server in anyway.
However, the reverse is not only possible, but is a common solution. Thus the Access (front end) is linked to SQL server and the data tables for forms, code, reports etc. for the Access application now resides on SQL server.
If you place the actual accDB data file from Access ON the SQL server, then SQL server can read the data, but any code, forms, reports etc. from Access cannot be used by SQL server. So a report in Access is of ZERO use to SSRS.
So if SSRS is a goal, then anything built in Access from a user interface point of view cannot be used. SSRS thus can only consume the data in tables.
Since SSRS can ONLY consume data from Access (and nothing else), then a far better solution in place of moving up a accDB file to the server is to simply push up the data from Access tables to a SQL server tables. And if such a data transfer is to occur often, then likely better is to ALWAYS keep the tables and data in SQL server, and have the Access front end part “link” to the data on SQL server. Access reports, forms and even VBA code will in most cases run as before, but the live data always resides in SQL server. You thus eliminate all the dance and song of attempting to transfer data between two systems. The SQL server data is thus always “live” and update to date, and only ONE copy of the table data EVER exists.
Most Access applications and reports and forms can work with very few (if any) modifications when you place the data tables on SQL server, and have the front end Access part “link” to SQL server.
Since a given specialized report in SSRS is going to require a pre-determined and non changing table structure, then the most prudent solution would be to have Access link to and use the data from SQL server tables (not the other way around).
So Access reports can ONLY be used by those with Access (or the free runtime) installed on each client desktop computer. Such Access reports have to be 100% re-built if your goal is to have such reports be used with SSRS.
I'm trying to use a combination of the SQL Server 2008 Reporting Services ReportServer database and the report server web service to determine the GUID for a particular report. What I want is to see a list of the previous names of a report that has been renamed or moved on the report server. I know a report's history snapshots stays with it when you rename it because the report has a unique GUID that doesn't change when you rename it. However, I can't seem to find a place in the database where previous names of a report are associated with the report's GUID. I can't find any instance of an old report name in the database, so I don't know if this is even stored. When I look at all the values of Catalog.Path and Catalog.Name in the database, the old values are not included from before the report rename. Is it possible, given a value like MyAwesomeReport, to associate that with a GUID like 7af3fe6d-b4ea-4cd8-8430-280392cba428, so that I can determine that this report has actually been renamed to MySuperAwesomeReport?
I think the easiest way for you to be able to determine a history for these is to build your own ETL script which would look up the current name of the reports, stored by GUID, and hold this in another structure. Having looked through the ReportServer database, I don't believe the name attribute of a report is held historically. I would based my implementation for this off the Sample Code for Reporting Utilization Stat's which is available in the examples on codeplex. I'll see if I can find the link to that example, its how I learned the most about how the ReportServer database is used and structured.
I have two SQL Server databases with identical schemas, but different data. I also have SSRS generating reports, in native mode, for one of the databases. All reports the same shared data source.
I would like to allow users to get reports for the other database. I created a second shared data source for the second database. Modifying the reports to use this second data source results in reports as expected.
Because the RDLs are the same, except for the data source, and because I don't want to maintain what are basically duplicate reports, I'm looking for a way to dynamically switch data sources, depending on user input.
Is there an easy means of accomplishing this? An existing solution would be best. Barring that, can the RDL's data source be parametrized? Or, can the RDS's connection string be parametrized?
You can use parameters or other expressions in the connection string.
See http://msdn.microsoft.com/en-us/library/ms156450%28SQL.90%29.aspx (2005)
or http://msdn.microsoft.com/en-us/library/ms156450.aspx (2008)
I'm going to piggy back on the last answer. Yes, use parameters in the connection string, but populate the data to ensure your users aren't seeing database names, etc. that you might not want them to see for security. You can store the values in a table, pass both the human readable and SQL Server specific values.
Does that make sense?
What's the best way to combine results sets from disparate data sources in SSRS?
In my particular example, I need to write a report that pulls data from SQL Server and combines it with another set of data that comes from a DB2 database. In the end, I need to join these separate data sets together so I have one combined dataset with data from both sources combined on to the same rows. (Like an inner join if both tables were coming from the same SQL DB). I know that you can't do this "out of the box" in SSRS 2005. I'm not excited about having to pull the data into a temporary table on my SQL box because users need to be able to run this report on demand and it seems like having to use SSIS to get the data into the table on demand will be slow and hard to manage with multiple users trying to get at the report simultaneously. Are there any other, more elegant solutions out there?
I know that the linked server solution mentioned below would technically work, however, for some reason our DBAs will simply not allow us to use linked servers.
I know that you can add two different data sets to a report, however, I need to be able to join them together. Anybody have any ideas on how to best accomplish this?
We had to do something similar (i.e. inner join 2 data sources from different servers). I believe the best way is to write your own custom Data Extension. It's not very difficult and it would give you the ability to do this and more.
You could add the DB2 database as a linked server in sql server and just join the two tables in a view/sproc in sql. I've done it, it's not hard and you'll get data in realtime.
You could create a linked server that would access the database directly or if you didn't want to strain the database during business hours, you could create a job to copy the data you need overnight.
SSRS 2005 allows you to have multiple datasets for a report. Each dataset can refer to a different datasource, one can come from a SQL DB another can be a ODBC source etc.
In the report designer view in Visual Studio go to the "Data" tab and add new data sources pointing to your different databases. Once you are done, when designing the report for each element you have to explicitly specify which dataset the data is coming from.
If the above does not work, you can write managed code, refer to http://msdn.microsoft.com/en-us/msdntv/cc540036.aspx for more helpful information and videos.
You could attach both the MSSQL tables and the DB2 tables to a Jet database and bind your report to the Jet database. I don't know the implications of the single threaded nature of Jet, or how much work would be delegated to the backing stores.