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.
Related
We do a lot of TFS analysis and reporting in Excel, using PowerPivot to map to 'executive friendly' terms (like dates vs iterations) and they are quite please with all that. However, we also now have several TFS 'projects' (instances, versions, whathaveyou), and an Excel workbook cannot link to more than one project at a time. Also as the projects grow larger and larger, my machine struggles to process. I'd like to put the mapping tables AND the TFS data from several instances into an Access database.
Question 1
Is there any way to link Access to TFS? If not, I'm fine having TFS data in Excel and linking to Excel, but with the 'header' TFS insists on putting in your export, the linked table has issues (like not having headers in first row, and then always having two erroneous records upon every refresh).
Question 2
Any thoughts on how to get around the funky header?
There is no native way to link Ms Access to TFS or to easily get rid of the header row that's added in Excel when linking a table. I'm afraid that the direction you're seeking will not help you in the end. It will only put all the computational pressure on Access instead of Excel.
The way to go here would be to setup the TFS reporting features, which offloads a lot of the processing to SQL Server Analysis Services (which can be used as a source for Excel) and reporting is provided by SQL Server Report Server in that case.
Unfortunately, the Reporting part of TFS hasn't had a decent update since 2010 and can be a bit archaic to use. For VSTS (the cloud-based version of TFS) it's now possible to link the account to PowerBI, which does everything you're after. This feature is not available on-premise though, it may be a great reason to move to the cloud. PowerBI can handle large amounts of data, can be connected to one or more VSTS accounts and can slice and dice data from multiple accounts and projects with ease.
In Business Intelligence Development Studio, what exactly is the difference between the objects (i.e., dataset, data sources, etc) in the Solution Explorer and the Report Data tab? Both have different datasets, but they impact the final report differently.
In the Solution Explorer you have Shared Data Sources and Shared Datasets.
These are self-contained items that can be deployed to the Report Server.
In the Report Data tab you have Data Sources and Datasets.
These are items that are internal to and relevant to the selected report only.
Both Shared Data Sources/Datasets and report Data Sources/Datasets perform the same function, i.e. defining a connection to a data source and extracting specific data from a defined data source respectively.
In an individual report, when you define a Data Source or Dataset (i.e. in the Report Data tab) you have two options - you can store all the details embedded in the report or you can reference a Shared Data Source/Dataset.
The advantage of using Shared items is that you can define the details and use the item in multiple reports, hence helping with maintenance and manageability. For example, from Books Online:
Shared data sources are useful when you have data sources that you use
often. It is recommended that you use shared data sources as much as
possible. They make reports and report access easier to manage, and
help to keep reports and the data sources they access more secure.
So, Shared items in the Solution define connections that can be used by multiple reports and are also deployed to the report server, while the items in the Report Data tab define those connections for the selected report; these can either reference a Shared item or have all the data embedded in the report itself.
More information:
Embedded and Shared Data Connections or Data Sources
Embedded and Shared Datasets
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?
We're looking for an easy way to display Access reports on the web. These reports have been written and viewed internally for years. They are not simple tables, but more complex charts and graphs. But, now people outside the organization need to see them. All of the data is in access. And, except for reporting everything else is working fine.
We have a web server that has permissions to see the Access database. However, the Access database server cannot be the webserver itself. So, the question is how do we view these reports on the web? This excellent solution, which I reference in case it helps others, (https://web.archive.org/web/20211020135306/https://www.4guysfromrolla.com/webtech/042600-1.shtml) does not apply, as it requires you to be on a company intranet . (Although, it may be possible to implement the solution outside of an intranet, so many security holes would be opened up that the developer leading this project would surely be fired.) If possible, we also do not want a solution that expects every client to install code, for example, the access runtime.
Is there a tool that can read the
access reports when requested? OR
Is there a tool that can upload the
data from the Access database on a
periodic basis and based on the last
retrieved data - it can display the
report that was written in access?
Other solutions ...
Thanks!
print the reports to pdf and then copy the pdf files to the webserver
Options:
output to PDF.
output to Access snapshot format and force users to use the snapshot viewer.
wait for Access 2010 with Sharepoint 2010 and Access Services and you're home free (as long as you can rewrite your reports to be full web reports, i.e., not VBA and only using the capabilities of web reports in A2010).
We deliver an Access app (and reports therefore) over a Terminal Server as a WebApp.
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.