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
Related
Beginning yesterday afternoon (12/9 Central US time) we began seeing a marked increase in SSIS packages execution failures. These packages have been in operation for several months and experienced no failures on 12/8. Initially I brushed it off as temporary, but now it seems as if "none" of them are working. Several of these packages run hourly, with the first failure around 10:30 on 12/9. Between 10:30 and 1500 'most' succeeded, but after 1500 on 12/9 most failed.
I'm testing with a relatively simple dataflow package. I have two sources (SQL and Sharepoint). From the sources, I compare the two and then update the Sharepoint list with any changes that have been made (SQL query is the authoritative record). The Source Sharepoint list is the same list that is being updated. As a further test, I removed all steps except for querying the Sharepoint list and sorting it. The initial query still fails.
Errors are happening inconsistently within the dataflow package. For example since I've been testing this morning, I had one (and only once) that made it through the package to the point it was should have tried to Add, Update or Delete list items. The table comparison resulted in updates to the Sharepoint list. The package failed when attempting to update the records. Most of them (and all recent attempts) are failing when the dataflow queries the Sharepoint list initially. There are only two records on the Sharepoint List and two records on the SQL table.
I'm connecting to Sharepoint using MS Graph. Testing the connection (Connection Manager) within VS 2019 has succeeded every time. I've verified that the secret I'm using is not expired. I created a new secret and am receiving the same error. 'Usually' if I attempt to preview the Sharepoint source that is successful, but not always. Even if it is successful attempting to debug and run the package fails. I'm not seeing any alerts on Microsoft or Azure that would provide any indication that the problem's there, though I feel like something must have changed there.
I have opened a support ticket with CozyRoc and they have directed me to open a ticket with Microsoft. Microsoft's support request workflow is directing me here.
In the production All Execution reports, the error I'm getting back is:
"Data Flow Task:Error: Attempt to read message string for 0xc02090f5 failed with error 0xc02090f2. Make sure all message related files are registered."
Initial research pointed me toward a data typing issue, but I've not changed anything in our Sharepoint, SSIS or SQL environment to have changed the data types.
This appears to be very repeatable so I can try providing more information if needed.
Look likes the answer was to wait. After about 1 week, the issue resolved as quickly as it appeared. I didn't find a way to report my issue directly to Microsoft without adding a support plan. I was in the process of finding alternative methods to address our needs when it resolved 'by itself'.
I just installed the latest version of SQL Server Design Tools for Visual Studio 2017 (in order to get SSIS templates etc.)
Prior to this I could right-click a report in Solution Explorer and choose run, and this would deploy and run just that one report, but not the others in the project.
Now it seems that when I do the same, all reports (and data sources) in the project are being re-deployed every time I try this. It's not a huge problem, but I liked the old way, in case somebody knows of a little setting tweak in there - I've not found it yet in search.
We had a similar problem when we recently upgraded our setup.
The first thing to note is that Run isn't typically used as a deployment model. It's supposed to be something used for testing, so the behavior you're seeing is likely related (in part) to that. To actually deploy a report, you should be using Deploy, which is right above the Run option.
Additionally, we often saw this behavior when VS could not completely build the entire solution. If you have any reports in your solution that don't build, or are missing (as in they're in the solution but not on disk), the overall build "failed".
That means that VS will continue to try and rebuild the whole project each time you build, run, or deploy anything. If you remove everything from your solution that doesn't pass, and then do this once, you should notice that behavior goes away.
Thankfully this bug was fixed in Reporting Services Projects 1.18.
So currently my boss and I are the two employees that work on our company's access database. I just got Office 2013 on my computer and he is will working with 2010. We have ran into some inexplicable bugs with the database.
Most of these can be fixed by just copying an old version of a form or report into the database when it fails; however, it is quite disconcerting when we spend hours trying to discover why something is wrong and are able to fix it without explaining why.
Most of the issues so far have occurred when I am using the db in Access 2013. So far the issues have been:
Access occasionally crashes and restarts when I am working in the VB code
Some forms bug out for no reason. It yet again occurs when I am working in the VB code if there is a compile erro. To further explain the "bugging out", the form usually contains about 2000 separate forms that you can search through, but when it bugs out it will only show one blank form. At first I panicked thinking all the table's data was gone, but nothing changed the table
There have been other hiccups, but nothing noteworthy besides these two
I guess my question is if anyone else has had issues along these lines, or if they knew of any other known issues. I tried to research errors people have been having, but I couldn't find anything besides Microsoft's official release of what features were being deleted.
As always, thanks in advance!
Your system should be split into two files. FE(front end) containing all forms, queries, code, etc., linked to the BE. BE(back end) containing the data tables only.
Maintain a development copy of the FE that is only used for making modifications.
Each user should have their own copy of the FE on their local machine. If you don't know how to split, just search for it as there are plenty of instructions out there.
I have 2010, but I worked with a consultant who worked on the same project in 2013. I too, saw some behavior that looked like version related bugs, but nothing definite.
Responding to your list:
Access occasionally crashes and restarts when I am working in the VB code -- This has happened to me in every version of Access I have used, from 97 to 2010.
Some forms bug out for no reason. It yet again occurs when I am working in the VB code if there is a compile error... -- If the compile error is severe enough to lose project state, this is not surprising.
Recommendations:
Decompile your application front-end occasionally, especially when 'weird' errors show up. See this SO link: automating decompile / recompile in ms-access
Compact & Repair at least daily while developing your application
Backup! Do this at least for every significant revision. Sometimes, the Access front-end will become so corrupt that it trashes all of your work. When this happens, nothing is recoverable.
I am not getting this error locally in VS 2005
or when running the report through the preview
but during subscription I start getting
ReportParameterValueNotSetException
even though all my parameters especially the one it's complaining about is set
this has started happening all of a sudden and has been working great before.
Any ideas why this might have happened
You could try deploying the report with a different name and see if subscriptions for it have the same problem. If it does not, then blame cosmic rays. It happens. In that case, delete the old report entirely from the server and then you should be able to deploy with the original name again.
If it continues to happen, then I'd start looking at what's different between running it live and running it through a subscription. Usually it's permissions related. Or perhaps the time of day the subscription fires off vs the time of day you test it live.
Is the parameter value used for the subscription hard coded, or is it based on another query?
If the latter
- does the query used for this param gen purpose work?
- does it return the correct datatype/expected data?
- does it work at the time you are running the report (database is online, has permissions set correctly)?
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:*