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:*
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.
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.
I've been requested to implement a means of reporting on add/update/deletes on files stored sharepoint (MOSS 2007). After a little bit of research I found out sharepoint has out of the box document auditing which I enabled a couple days ago. I ran the report today, but excel spreadsheet was not very easy to look at.
Also I'm not positive of this, but I believe only site collection administrators can generate thsi audit report, and I dont really want to give the people who want these reports that much permission.
I'm curious what are some alternatives or recommendations? Should I try and get this information off the sQL Server and display it in reporting services, or perhaps try and build a include it in a dashboard?
Thanks
If you have access to the SSRS instance for SharePoint, you can get the report file. You can then make a copy and edit for the report you would like. permissions are a separate issue that can be tackled however you desire, especially if you create a copy and store as a new report.
I have an interesting issue with TFS reports. When I run the QUERY: Team Queries->Planning and Tracking->Work Breakdown, I see the correct information, which is to say that I see the work items, etc. that are entered into TFS. However, when I run the REPORT: Reports->Project Management->Requirements Overview I see that same data PLUS data that is no longer in the system.
Important information:
* I am using TFS 2010
* When I originally created this project, I used a Microsoft Project plan to upload the work items. Before my team started using it, I decided to forget about Project and just use the web/studio interface, so I used the query "Delete all items" to clean the database.
While the clean worked in all other cases, this report seems to be holding on to those items, and I would like to know if there is a way to fix that. It has been several weeks, and I ran the cube reports to see if it was updating (everything updates fine).
Anyone have a clue what's going on here?
I'm not familiar with the query that you talk about, but if you do a delete of workitems, the delete may not have been propagated to your warehouse (and subsequently the cube). If you have a relatively small number of WorkItems in your TFSWorkItemTracking database, it may be a good idea to rebuild your TFSWarehouse, which will then refresh your cube.
Take a look at the SetupWarehouse.exe command, which should be installed on your Application Tier. This could take anywhere from an hour to a day to run, depending on your version control and work item tracking database, so you may want to do it off hours. It shouldn't affect the day-to-day execution of TFS, just the reports.
The above is for TFS 2008 Only. Per Matthew below, here's the answer for TFS 2010
From what I found SetupWarehouse.exe
no longer exists with TFS2010. In the
Administration Console, under
Application Tier->Reporting, there is
an option called "Start Rebuild".
Using this completely resolved my
problem. Thank you. It should be noted
that there is NO feedback from
clicking on "Start Rebuild". At first
it looked like the admin panel hung,
then it came back without feedback. It
took about an hour for reports to
start working again, which is the only
way I knew it was done.
If you ever get into the situation again where you need to permanently get rid of one or more workitems, you should get the TFS Power Tools. The TFPT utility has a "destroywi" command that allows you to permanently (and safely) remove workitems from TFS.
Power Tools are available here: http://msdn.microsoft.com/en-us/vstudio/bb980963
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