We had a problem earlier when deploying a single report to the production environment, when, for reasons we don't understand, SSRS decided to also overwrite the Data Source associated with the report with settings that do not even match those currently in the project.
We want to understand why/how this happens, and what we need to be doing to control it - ie, what are we missing about SSRS that we need to be aware of.
The steps we took were as follows:
Before starting: This is to update an existing report, not a new report, so the Prod report server already has the Data Source and the (old) Report Definition. The Data Source (shared) does not need to be changed at all, nor do we believe we did anything that should have prompted SSRS to do so. We only intended to overwrite the old report definition with the new one.
Data Source within project modified to point to the production Sql Server source
Deployment settings within the project modified to point to the production Report Server
The single report deployed (literally by right-clicking TheReport.rdl in the Solution Explorer and then clicking Deploy). That is everything we did. We did not deploy or change anything else.
Expected result: report definition on the prod server overwritten with the new report. Data Source completely unchanged, because why would it be? We didn't deploy that (and in any case, the one in the project is pointing to prod, so it shouldn't even matter if it did)
Actual result: Report overwritten as expected. Data Source also overwritten... with the old dev settings. Not the ones currently in the project. All the other reports sharing this data source suddenly stop working or display dev server data.
What are we doing wrong? SSRS quietly overwriting the associated Data Source on the server when deploying a single report seems dangerous (we would likely have missed that it had even happened, had the data on these particular dev and live environments been similar enough) so I presume we are missing something we should be doing/checking when deploying reports, but are at a loss as to exactly what.
That is configuration to copy your datasources and datasets to the report portal or not. You can change the configuration by right click on your report project and select properties that will open up the property pages. There is an option to overwrite default settings. Please check below image for more details
By using the above configuration it will deploy dataset and data sources on SSRS server only if it is not exists on the server.
Hope this will work.
Related
I'm looking at some issues with a migration of a huge amount of rdl's, the guy that has done this has shifted them and they work, so that's good.
But... if I download one of them the datasource is still the original datasource not the one he changed it to using the web interface.
If I download it, its the old db connection. If I view via the web interface it shows the correct datasource, and then... if I right click and edit through report builder (via the web interface) it shows the updated datasource.
If I save it updates it as I would expect.
Am I missing something here?
Personally, I would never edit a report via the web thing, I would always edit the file and redeploy.
Is there some way I can republish them all without opening each one and saving (I'm 85 into 450 of them and am bored shitless!)
This is both a question and a possible answer. Have you restarted your instance of SSRS? If the data source is shared, and has been modified, you shouldn't have to open the reports in the builder for them to reflect the modification, so alternatively it sounds like the connections are cached and a restart should clear that up.
I have a tabular model that I've processed and deployed.
I'm having a problem getting SSRS to reflect the newly deployed information. I have a shared Dataset accessing a shared Data Source. When I run the MDX in the query designer of the Dataset, the correct numbers are returned. When I run the report, however, the old numbers still show. I've tried deleting the .DATA file but it didn't help.
EDIT:
I've verified that the problem is in the SSAS database itself. I queried it with drillthrough from SSMS and saw that it is returning rows that aren't in the source views any more. They used to be, but no longer.
This almost seems to be some crazy caching issue. I've rebooted and dropped/redeployed the SSAS database and no luck.
Any thoughts?
I would suggest a few steps.
Ensure you are connecting to the correct tabular model.
Expand the tables in the tabular model, and right click one of the tables and click "Process". Check all the additional tables in the model.
Change "Process Default" to "Process Full" (Process default does not always work correctly)
Click Ok.
You should now see the model process table by table.
I would close and re-open the report.
Actually I would completely ignore the BIDS / Visual Studio Preview pane as it is riddled with bugs and inconsistencies and proves nothing (assuming your end users aren't using Visual Studio).
Instead I would deploy the report for each test run to a test environment / folder on the host server (Report Manager / SharePoint). As well as being a realistic and meaningful test, this has many advantages such as being able to leave multiple IE tabs open with various parameter combinations set, then just refresh them after a Deploy to retest.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
We currently working on an application where we are asked to generate reports. Our immediate choice was to use SSRS. After studying tutorials we successfully completed designing of all reports. However, I was not clear on how to deploy an SSRS Project for displaying them in a GUI environment.
My questions are:
Where should we deploy this project?
If we deploy in IIS, which server will run it?
Does IIS have the capability to run these?
Do we need to run any report server to run these reports?
Please any any clarification regarding these aspects.
I know how to create reports, but I am struggling with the basic concepts of SSRS. I.E. I need more information on how to setup in a production environment.
There are three parts to every report so let's cover those first:
A DataSource which is the connection string or equivalent to talk to a database, service or flat file. This can be contained in the report or shared. Shared matters in that a shared datasource may be used by one or many reports.
A Dataset which is a query, procedure or structure of obtaining data to be used in a report. This may also be contained in a report or shared. Again shared may be used with one or many reports and may be cached on a server.
The report itself. For the most part the RDL language is a proprietary microsoft language based in XML that takes one or many table, matrix, chart or other display elements and presents data that has been formatted for viewing through one or many datasets talking to one or many data sources.
Deployment in the simplest possible way could be the bold at the very bottom if you are familiar with Business Intelligence Development Studio. However there should be some checks done from the top down of a few things checked first:
Do you have an SSRS instance running on a local instance or a server in a domain you can talk to? You need to ensure the Server running SSRS is actually on and working. On the installation computer you should find it quite simply with All Programs>Microsoft SQL Server (vers)>Configuration Tools>Reporting Services Configuration Manager. Once this tool comes up it will attempt to prompt a window with ServerName and Report Server Instance. The default instance is usually MSSQLSERVER for SQL Server Standard or higher.
If this works great, if not you either never installed SSRS or the service is not running.
**If you believe you did it may not be running the service yet. Go back to All Programs>Microsoft SQL Server (vers)>Configuration Tools>SQL Server Configuration Manager. This will show all services that SQL Server is currently running, including SSRS if it was installed correctly. When it comes up go to 'SQL Server Services' on the left pane and you should see the equivalent of 'SQL Server Reporting Services (SQL instance)'. If it is stopped, start it. If it is not there you need to insure the installation of SSRS was successful or may be on another machine.
If 2 was successful you can hit 'Connect' and you now have a few panes on the left. For the time being deployment should focus on two of those panes 'Web Service URL' and 'Report Manager URL'. One is the ACTUAL SERVICE and the other is just a hosting location the user will see. Click on 'Report Manager URL', you should see a virtual directory and then a link like below. Click on this link and you should be able to get in.
http:// (servername)/Reports
If you could not get in it was probably due to you not being the administrator who installed SSRS or an equivalent admin. You need to be an admin on the server that installed SSRS then and click on this site. Once in you need to add relevant users under "Site Settings" in the upper right under Security. You not only need to do this but also under "Folder Settings" Security do this again. If you are deploying and altering reports you will want to be an 'admin' for the first site settings and a 'content manager' for the second. We need to ensure dedicated users can get to this page before continuing so ensure this can be done.
Once you can do above go back to the SSRS config manager and click on 'Web Service URL' on the left pane. You should see a virtual directory, default is 'ReportServer', and an identification section that generally is set to port 80. Below that is an URL that is most commonly. Click this and ensure you can go to this site as well.
http:// (servername)/ReportServer
Did you notice that this url is similar but different to above? This a huge step that a lot of people new to SSRS miss and end up having their whole deployment process not work.
If you can do both URL's above you are now ready to configure a solution for deployment. The easiest method to deploy code to an SSRS server is with the Visual Studio add on labeled 'Business Intelligence Development Studio'. You get this when you should have installed SSRS, however if you are on a different machine you may get this add on with either SQL Server Standard with advanced Tools or SQL Enterprise. To get to this the versioning is weird, they should match the Visual Studio Edition to the SQL Server version EXCEPT FOR SQL 2012, that is on VS 2010. If you are not sure you can again get to this under All Programs>Microsoft SQL Server (vers)>Business Intelligence Development Studio OR SQL Server Data Tools.
Once you have this tool you would open it up and create a new project 'Report Server Project'. There are tutorials on how to work with IDE but I want to focus on deployment so you should generally have one or many projects under a solution. Right click the project and choose properties. For SSRS deployment this is were everything is done. The main properties are as such (I will not go over all, you may have more):
Overwrite Datasets: False is default (should be kept, you may override if need be)
Overwrite DataSources: False is default (same as above)
TargetDatasetFolder: Datasets(you can change if need be)
TargetDataSourceFolder: Data Sources(same as above)
TargetServerURL: (blank)
The main key to SSRS deployment that 80% of people get confused about first is you deploy to the SERVICE NOT THE REPORT MANAGER URL. So you would put in http:// (servername)/ReportServer to the TARGETSERVERURL, not the other one. So many people say that SSRS deployment just will not work for them and it ends up being they did the targeting wrong.
Final step: You can create folders and datasources and even deploy to multiple locations all at once. But be careful, this is a powerful thing to set up and be aware of this. At the top of Visual Studio there is a ribbon for 'Configuration Management' that is by default selected to show the drop down 'Debug'. Click the drop down arrow. You should see one or many projects you have and you can choose to just 'Build' or also choose to check the 'Deploy' option as well. This would help if you wish to build and deploy to multiple environments or perhaps you can set up another configuration for different environments for QA, DEV, PROD, etc here as well.
If you just want to get started from BIDS follow step 6 and just right click a project and choose 'DEPLOY'. This will deploy all shared objects first (but not overwrite if set to false) and then reports. You may also highlight individual items and choose deploy as well.
First you will need to build the folder and then deploy the report.
You will need to set the url and folder in by right clicking the project on the solution explorer. Here you can set the url as well as the folder location.
About half way down this link, there is a step by step visual on how to deploy a report.
http://www.codeproject.com/Articles/194097/SSRS-Series-Part-I-Various-ways-of-Report-creation
I hope that gets you off to a good start!
I've inherited a live SSRS server and have been asked to amend a lot of reports that are on there.
Is there a quick way I can "export" all of the reports/data sources to a local instance so I can develop against it using BIDS?
e.g. Can I copy the ReportServer database from Production?
What else would I need to do?
I'd like to be able to have a Development copy of everything, with DataSources pointing to copies of the production databases but with the same names. Therefore I could re-write the report and re-define any SP's required locally, and then just deploy the new RDL to the server along with the ALTER SP scripts.
Is that possible or even sensible!?
Personally, with the volume you mentioned in the comments (30 RDL's and 3 databases) I wouldn't recommend some automated cloning of the entire Reporting setup from production to local. Instead, I'd suggest the following:
Reports
Go to the web front-end for your reportserver (typically http://yourserver/reports). Find each report, open it, and on the Properties tab click the Edit button. This button does not do what you might expect (edit the report inside the browser), but instead offers you a download of the RDL file. Save all the RDL files in one folder on disk.
With 30 reports manually downloading the reports may take you maybe an hour, max. This will probably beat most automated approaches. And since you should only need to do this step once...
Databases
It's not entirely clear from the question, but if you only have production databases and no DTAP setup yet, now may be a good time to start with that. You could host clones of the 3 production databases on a test server or possibly on your dev environment. Note that the schema's important here (should be the same as production), the data doesn't have to be entirely up to date.
Alternatively you can skip this bit and develop your reports against the production databases, assuming you can create connections from your dev machine to the production databases. Up to you.
Visual Studio / BIDS
This bit has a few parts to it:
Create a new reports project and solution in Visual Studio.
Add the existing RDL files you've downloaded earlier.
Depending on how the reports were set up, you may need to add shared data sources in your project, to get your reports up and running.
After all this, you should be able to preview your reports from Visual Studio (either with data coming from the "cloned" databases, or directly from production).
At this point you should also be able to safely make changes and preview/test them before deploying them.
Be sure to add the solution, reports, etc. to your version control system of choice.
Deployment
Once you've made changes you want to deploy to the reportserver, you have two basic options:
Deploy them using BIDS (see also the deployment properties MSDN page)
Go back to the web front-end, find the report, open the Properties tab again, click the Update button. This allows you to re-upload the RDL file with the changes you've made.
From now on you can just rinse and repeat on making updates and deploying the reports. No need for cloning/exporting the entire SSRS instance to keep things in sync.
Whenever I wish to debug a single report (.rdl file, Report Definition file), it always deploys everything in the solution. Can someone recommend a deployment strategy in order that I can localize deployment to the specific report I am working on, and not clobber the other reports in the solution? Those may have been worked on by another employee, and why should deployment occur across the board?
Right clicking on the specific report to deploy and choosing "Deploy" from "Solution Explorer" always works for me. Also, I keep OverwriteDatasources to false unless I specifically need to update that.