Partager via


TFS 2010 Upgrade to RTM breaks IterationParam reports

With the release of Visual Studio 2010 RTM, we embarked on upgrading from RC1 to RTM.  This was a rather seamless process with no “unexpected” hoops to push through though I did recently encounter an issue with some of the customized linked reports I built.  As shown in my post TFS 2010 – Using Stories Progress in your Dashboards but scoped to iteration or areas, you can easily modify your reports to scope them as you see fit.  We’ve done this for several of our on-going software projects and we recently noticed that after the upgrade all of these reports were broken.

IterationSK Value changes between RC1 & RTM

The root cause of the failure was related to an invalid value provided for IterationParam.  When checking, I noticed the nice number for the iteration (34) and then I decided to check it in the database.  To review, in the database I would do the following:

 select IterationSK, IterationPath
 from DimIteration
 where IterationPath like '{insert your iteration name here like RTM}'

When running this query, the query executes but fails to return any values.  This is odd as this worked fine in RC1.

image

After digging a bit into this, I noticed that a dump of the table DimIteration had a field named “IterationName” and so I went the next step and changed the query to -

 select IterationSK, IterationPath
 from DimIteration
 where IterationName like '{insert your iteration name here like RTM}'

As you can see, I used IterationName instead of IterationPath and then provided the friendly name for the iteration (like RTM) and it returned the correct values.  The ironic thing is the value had changed which was causing the failure for the reports

image After locating the value (155), then I can easily edit the parameter for IterationParam to this value and the report renders with no issue.

Summary

I would suggest everyone be a bit careful when they bless “RTM” upgrades as clean and no issues as you never know when you will get this weird issue like this.  In this case, a similar query (IterationName vs. IterationParam) solves the problem and is easy to snap into your report and off and running you go.

-Chris

Digg This