Rank 1
The burndown reports also show this same graph.
11 Answers, 1 is accepted
My first suggestion is that the burndown might be showing zero-value for a future date (for 24th while the local time of the client machine is the evening of 23th).
Can you send us some more information about:
- what is the time zone of your TeamPulse host machine;
- what is the time zone of the machine that hosts the SQL Server (in case you are using remote SQL Server);
- does the problem appear constantly or happens just in a particular period of the day;
- what happens when a new day comes - does the zero-value get replaced with a real value or remains zero from this point on (this and the previous one would require observation at least till tomorrow if the problem appears now for the first time);
- have you customized the time when history is generated for your TeamPulse instance (that is made from the <TeamPulse-installation-folder>\IntegrationService\Telerik.TeamPulse.Integration.Service.exe.config) - if you haven't made customization the default time is set to HistoryGenerationTime="00:00:00";
Oleg
the Telerik team
Want to know how TeamPulse could help you better track all your projects?
Rank 1
It does appear only at certain time of day. When we do the scrum meeting (10pm Central US) it appears incorrect. The scrum is at this time to accomodate team in India. I can verify that during the work day here it appears fine.
As such, should I be changing the HistoryGenerationTime?
For now probably you won't need to change the HistoryGenerationTime (from your answer I understand it is left as default) - I needed to know if it is changed in case it turns to be relevant to your case. Usually the default value is fine for most clients and customization is used just in specific cases.
I can guess that the problem is related to using separate machines with different time zones for a TeamPulse host server and SQL server or the SQL server time itself. Still I need information about the system time of your server machines.
Could you check those machines (if they really are separate in your case) and tell us:
- what is the time zone set for the system time of your TeamPulse host machine (e.g.: UTC -05:00)
- what is the time zone set for the system time of the machine that hosts the SQL Server (e.g.: UTC -08:00)
All the best,
Oleg
the Telerik team
Want to know how TeamPulse could help you better track all your projects?
Rank 1
- TeamPulse and SQL installed on the same server and the time is set to UTC -8:00 (Pacific Time)
- Around late afternoon (~5pm) management notices that the burndown drops to 0. The time is approximate as I haven't had a chance to monitor it minute-by-minute to determine when exactly. I know the next morning the graph looks ok again.
- We have not changed the default settings:
This problem really should only be an issue when SQL Server is running in a different time zone from the web server hosting TeamPulse. The problem is that several of our queries used to report daily burndown values are executed within SQL and are not accepting a date offset parameter, but rather just using the date offset of the SQL Server itself. This then becomes an issue when the web server is running on a timezone ahead of the SQL Server and asks for the daily values. The web server believes it is, as an example, March 16th, but the SQL Server thinks it is still March 15th and only returns values for days up to and including March 15th. As such, the web server displays 0 values for the 16th (current day), until such time that the SQL Server catches up and has the same date as the web server again.
David Harris
the Telerik team
Visit our Ideas & Feedback portal to submit a feature request, vote on existing requests or submit general feedback.
Rank 1
I can confirm that the database and web server is on the same server since my db connection string is set to local.
<add name="TeamPulseConnectionString" connectionString="server=(local)\SQLEXPRESS;Integrated Security=true;DATABASE=TeamPulse" providerName="System.Data.SqlClient"/>
Is it possible it's something else? Or is there other information I can provide?
Thanks for the feedback. We will need some additional help from your side to reproduce the issue.
I've understand that the time zone on your local machine and on the server are the same. But have you changed the time zone on the server?
Do you work with people in different time zone? If the answer is yes which is their time zone and what kind of changes they are doing?
Can you send me few things so we can try to reproduce it?
1. Your current time - 5pm (already have it)
2. Your time zone - PST(-8 hours) (already have it)
3. Data that is used to generate the burndown. You can get the link to them from the dashboard rss link and add the data between the iteration ids and the rss. The link should be something like http://[url]/Feeds/ChartFeed.svc/chart/burndown/iterations/i394/data/rss?mode=TaskEstimate
4. Run the following SQL script in SQL Server Management Studio and save the result as csv
SELECT * FROM [TeamPulse].[dbo].[DailyHistoricalTaskByIteration] (394)GOGreetings,
Jordan
the Telerik team
Visit our Ideas & Feedback portal to submit a feature request, vote on existing requests or submit general feedback.
Rank 1
I created a support ticket and provided the information you requested because I didn't want to post on public forum. Thanks.
Rank 1
Unfortunately a fix to this bug has not yet been released. We track this bug with ID# 3055 and I have noted in the description to contact you and/or reply to this thread when a fix is released. If at any time you have any questions about the status of this bug please contact us and reference ID# 3055.
Regards,David Harris
the Telerik team
Visit our Ideas & Feedback portal to submit a feature request, vote on existing requests or submit general feedback.
The bug is fixed in the latest R6 release. You need to wait a day so the history can be generated. After that the Burndown should be fine.
Regards,
Jordan
the Telerik team
Visit our Ideas & Feedback portal to submit a feature request, vote on existing requests or submit general feedback.