I have a SSRS report. This report has two data sets from two different data sources. I need to do a conceptual join on these two data sets. For example, assume I have the following datasets A and B.
DataSet A
Data Source is SqlServer P
SELECT user_id, user_name from users
DataSet B
Data Source is SqlServer Q
SELECT change_id, user_id, change_details from changes
Eventually, I just want a SSRS table with user_name and change_details. After a little online research, I've found three options:
- Join the queries in the dataset using server linking from SQL Server.
- Join the queries in the dataset using openrowset() from SQL Server.
- Use an external assembly to make a web service call and cut out the 'users' datasource.
- Conceptually 'join' the datasets using a report/sub-report paradigm in which the report's grid has a sub-report that just takes the user_id for a given row and populates a single text box with the user name.
They all feel like they have some headaches. Of these, I think I prefer option 4 because it forces this 'join'ing logic into the report and leaves the queries simple. In addition, it allows me to skip alot of overhead setting up linked servers whenever a report is deployed to a different environment. Option 1 looks doable as well, and all of the querying would be encapsulated in the dataset. Option 2 doesn't look strong because all of the documentation for openrowset seems to say to use linked servers instead. Option 3 is currently not feasible with all of the required setup to use external assemblies, but I think this would be a viable alternative otherwise. With this said, are there any other reasons for choosing one of these solutions over another?
I'm working in SSRS 2008 if that is relevant.