Traditionally, our plucky team of developers have always migrated our own reports into production. This task is now being taken up by our support staff, who'll need detailed instructions to do so.
We have always deployed straight from VS2005, which can be made available to the new migrators. Is there a better way to migrate these reports without VS2005?
Also, we need to provide some backup and rollback instructions. Have to confess, SSRS reports are probably the only thing I haven't backed up prior to a migration ( I normally take the "hey, they're only reports!" view ). Does anyone know of a good resource which covers backup of reports prior to deployment of replacements?
Have a look at this, it will backup all your reports using a script. I've used for migrating reports between servers. If you open the script file that it generates, you'll get a good idea how to generate your won scripts that you run using the RS.exe utility built into SSRS.
http://www.sqldbatips.com/showarticle.asp?ID=62
Related
It is not the first time this question has been asked, but no solution has been found yet. The only thread I found somewhat relevant was this but it is 4 years old: SSRS Reports Versioning
Perhaps a solution has been found since then?
Back to my questions:
I have several reports in a Visual Studio solution (BIDS). From here I can deploy to several reporting servers: Test1, Test2 and Production.
1) It seems that the granularity of deployment is: Reports, Datasets and Datasources. This can be setup in Properties for the solution. But I want to be able to only deploy a single report, if I only have changes to one report. How do I do this? As it is now it seems that I have to deploy ALL reports.
2) Since I have more than 1 place to deploy there is a possibility of the reports getting out of sync. Normally the procedure would be to deploy the reports to Test until everything is fine, and thereafter deploy to Production. But since this is a manual process something can go wrong. Therefore I believe it would be nice to have some sort of versioning on the individual reports. But I can find no way of doing this? I'm thinking that it would be really nice if a timestamp and/or versionnumber could be set on the reports when they are deployed. Is there a way to do this?
Thanks in advance.
How about putting the version number of the report on the report itself? You would need to run the report to see it though.
To deploy a single report, right-click on the report name and Deploy to deploy that report (or dataset or data source).
As far as the deployment issues, you can use version control such as Visual Studio Team Foundation Server.
https://www.visualstudio.com/en-us/products/tfs-overview-vs.aspx
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.
We are developing an application with Visual Studio 2008 and TFS. Our database is a MySQL DB. As we develop we keep the new queries that need to be applied to the database of our new release as the New Version Update Queries. Right now I'm keeping them in a simple text file (which is a painful task!). I know that TFS integrates with MSSQL and makes this job very easy. I've already asked our consultant from Microsoft if there is any way to integrate TFS and MySQL, and his answer was "NO". So I was wondering if anyone knows any smart way of handling this issue?
I think the question may be a little misleading in that I think you're saying TFS when you mean Visual Studio. My guess is that you are looking for a MySQL provider to hook into VS2008 so you can use the database developer features (DataDude) with it? TFS itself is simply a server that provides source control and work item tracking services and isn't designed to work with anything other than MSSQL.
Visual Studio's data tools can be hooked into other databases using the Database Schema Provider interfaces (it's a 2010 feature). An implementation exists for Oracle, but nothing yet exists for MySQL.
My suggestion would be to store your scripts in TFS as regular source controlled items, and keep doing what you are doing until someone writes a DSP for MySQL.
I'd like to create a simple report that shows files that currently have pending changes (checked out) from a TFS 2008 server. I know that I can use the "Find in Source Control" option from Team Explorer, but I would rather generate a reporting services report. Ideally, I'd be able to show when the file was checked out and the user that checked it out, but that's not imperative.
If the data isn't pushed to the TFS data warehouse by default, then I'd like to find the relational table(s) in the SQL Server instance that would need to be queried.
I've spent some time digging around the TFS data warehouse and looking at all of the canned Reporting Services reports that I can get my hands on, but everything seems to be geared towards work items, check-ins associated with work items, etc...
If you're looking for some easy to read data and not too worried about print outs, have a look at the TFS sidekick application by Attrice. Very helpful and if you have the correct permissions, you'll be able to see all the checked out files.
http://www.attrice.info/cm/tfs/
I doubt the information you're looking for is in the data warehouse and even if it was it might not be fresh enough for your purposes. By default the warehouse is updated once an hour.
You could use SSRS to report directly against the TFSVersionControl database but I would not recommend going this route. The database is not documented and chances are very good that it will change in the next version. It could also have performance implications if your queries are not written correctly.
A better solution would be to use the TFS web services as your SSRS data source. There are services you can call to get all files that are checked out. This iformation is always current and the queries it runs are highly optimized.
Example command line (Studio 2008):
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\tf.exe" status /recursive /user:*
It seems very easy to deploy new reports to a reporting server directly from visual studio, however when these are to be pushed into our web farm (where developers have no access), this either needs to be done manually, report by report, through microsoft's web front end, or into an MSI.
However, from time to time we might want to reconfigure report options on the report server such as, changing the data source for all reports or changing the caching options for them. Rather than create a whole new MSI for each set of changes or do this manually I wondered if anyone knew of any alternative tools that can update multiple reports at a time or even able to deploy the contents of a folder into a folder on the reporting server.
Cheers, Chris
For Administrators, rs.exe, http://technet.microsoft.com/en-us/library/ms162839.aspx , allows remote scripting via VBScript. If it's possible to give SOAP access, you should be able to accomplish all you want and more without resorting to an MSI.
Thanks, Jamie
Microsoft Reporting Services - Developer