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?
Related
In my client environment there are many SSRS reports have been deployed. Each having separate data source and it is pointing same server and same database.
Is it good that to convert into single data source based on the database base. Will there be any performance issue or any other issue will occur? Please suggest me.
If you need Manageability then please go with a shared data source.
As far i'm aware, there won't be any performance issues.
When you create a shared data source, all of the connection information for the data source you’re connecting to is stored outside of the report, and deployed as its own object. Other reports are able to reference the shared data source.
On whether its good to convert into single data source based on the database base, i would say it depends, but in general I tend to use the following guidelines.
If I have multiple reports that are going to be referencing the same data source, a shared data source makes perfect sense
If I have a data source that I know is only going to be used by one report, and never by any others, then an embedded data source might make more sense, although this is kind of a rare case in my experience. If you do created an embedded data source and start getting requests for other reports using the same data source…you should definitely convert it to a shared data source.
The advantage of using shared data sources starts to become evident once you start to have a large number of reports to manage. If you have to point your reports to different environments like dev / QC / Stg / prod, you can change all the reports at once by simply changing the information in the shared data source. Had you created all your reports with embedded data sources however, you’d have to edit each report individually, and if you have a lot of reports, that can translate into a lot of work.
We are considering migrating to Sql Server 2005 Reporting Services. Many of our existing reports require pre-processing of the data before rendering it.
For example, we have a query for a report that returns GPS coordinates (Latitude and Longitude) from a stored procedure, but before passing off the DataSet to our reporting engine (currently Crystal) we call out to a Web Service to reverse geocode the coordinates and get an address string. We push this into the DataSet object.
I've read a bit about Data Processing extensions but I'm not sure that's what I want, as then (if I understand correctly) I would need to implement the entire processing flow (including retrieving the data from the stored proc) just to massage it a bit at the end.
How can I interject and pre-process the dataset after retrieving it from the data source, but before passing it on to the renderer?
You could create a .NET assembly with a method in it that processes an individual record. Then, include that assembly in the report, and call that method when each row is being rendered. This would do the processing and display the result.
For instance, after creating the assembly and adding it to the report, you could have a table where one of the cell expressions looks like this:
=Code.ReverseGeocode(Fields!Latitude, Fields!Longitude)
See http://msdn.microsoft.com/en-us/library/ms155798.aspx for some guidance.
You can also use the results of an SSIS package as a data source (the package is executed on demand when the report runs).
This can be very helpful if you are trying to solve the problem of joining data from multiple data sources into a single dataset for example: a geocode web service and a relational result set.
I don't think a lot of people realize that this exists and how useful it is for handling EII type reports
One option would be to use a ReportViewer control in local mode.
The data is loaded into ASP-NET, you can the pre-process it, then pass it to the control for presentation.
I'm not sure of how SSRS would deal with custom code/DLL when you want to process all data before thinking about presentation (as in the =Code.ReverseGeocode solution mentioned). RBAR feels wrong at the text box or cell level.
I guess I don't understand why you just don't write the SQl to provide the data the way you want it. Can't you calculate the field through a function or use a where clause to filter the data further. You can do quite extensive data manipulation in a stored proc or query data source.
Rather than generate my RS reports by directly accessing a SQL database, I'd like to take advantage of Domain Objects I've already written in another application, where complex business rules and calculations already exist so that I don't have to duplicate that logic in stored procedures and other code. I want to keep it DRY.
It would be nice to treat the reporting concern as just another type of view
Is that possible with Reporting Services? It seems logical that it should be, but I'm not finding much information out there.
Yes. You can use the ReportViewer control in Local Processing mode. In this mode, you can just pass a DataSource instead of directly accessing the Database.
Keep in mind that there are certain things that you cannot do in LocalMode that you can in ServerMode. One that I recall, is exporting to anything other than PDF or Excel.
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.
I am developing a Reporting Services solution for a DOD website. Frequently I'll have a report and want to have as a parameter the Service (in addition to other similar mundane, but repetitive parameters like Fiscal Year, Data Effective Date, etc). Basically everything I've seen of SSRS 2005 says it can't be done... but I personally refuse to believe that MS would be so stupid/naive/short-sited to leave something like sharing datasets out of reporting entirely.
Is there a clunky (or not so clunky way) to share datasets and still keep the reporting server happy? Will SSRS2008 do this?
EDIT:
I guess I worded that unclearly. I have a stack of reports. Since I'm in a DoD environment, one common parameter for these reports is Service (army, navy, etc. for those non US users). Since "Business rules" cause me to not be able to use stored procedures; is there a way I can make 1 dataset and link to it from the various reports? Will Reporting 2008 support something like this? I'm getting sick of re-typing the same query in a bunch of reports.
I am not clear if you need to share a dataset, since you have some SQL results that you need to use twice, and don't want to re-compute the same data twice, or you want to do something regarding parameters. So with this "I didn't really understand the question" preface...
You cannot share a dataset. Meaning, you can't, lets say, have a dataset returning table A, and in dataset B try to join with A.
If this is really what you want to do, you could use temporary tables to store A and then in dataset B use the temporary table. There are best practices around that, but since I am not sure this is what you need, I won't spend time talking about that right now.
If you cannot use Stored Procedures, I hope you can use a view.
Else you could leave SQL Server and use CSV sheets as data storage.