Hey everyone, I’m in a bit of a pickle with our team’s timesheet setup. We’re currently using both TFS 2010 and TFS 2012, and we want our timesheets to show work items from both systems. The thing is, we’re not moving everything to 2012 anytime soon.
I was thinking, maybe we could tweak the stored procedure to grab data from both TFS 2010 and 2012 databases at the same time? That way, we’d have all our work items in one place without having to switch between systems.
Has anyone tried something like this before? Or do you have any other suggestions on how we could make this work? I’m open to any ideas that could help us streamline our timesheet process. Thanks in advance for your help!
I’ve actually dealt with a similar situation in my previous job. We ended up creating a custom middleware solution that acted as a bridge between the two TFS versions.
It wasn’t perfect, but it did the job. We wrote a small application that queried both TFS 2010 and 2012 databases, merged the data, and then exposed it through a simple API. Our timesheet system then pulled from this API instead of directly from TFS.
The trickiest part was handling the differences in data structure between the two versions. We had to do some data transformation to ensure consistency. Also, performance was an issue initially, so we implemented caching to speed things up.
It took some effort to set up, but once it was running, it saved us a ton of time and headaches. Just make sure you have good error handling and logging in place. And don’t forget to consider security implications when accessing multiple databases.
If you’re comfortable with coding, this could be a viable solution for your team too.
hey noah, i’ve been there! instead of messing with stored procedures, have u considered using a reporting tool like Power BI? it can connect to both TFS versions and merge the data into one view. might be easier than coding something custom. just a thought! lemme know if u wanna chat more about it
Having worked with multiple TFS versions, I can tell you that merging timesheet data isn’t straightforward, but it’s doable. Instead of modifying the stored procedure directly, consider creating a separate consolidation process.
You could set up a nightly job that extracts relevant data from both TFS 2010 and 2012 databases into a separate, consolidated database. This approach keeps your source systems untouched while providing a single point of access for timesheet reporting.
For implementation, use SQL Server Integration Services (SSIS) to create ETL packages that pull data from both systems, transform it into a consistent format, and load it into your consolidated database. This method offers flexibility and scalability as you eventually transition fully to TFS 2012.
Remember to thoroughly test and validate the consolidated data to ensure accuracy across both systems. Also, factor in any performance implications on your production TFS instances when running these extraction processes.