One problem I have with hosting my DNN websites is that, most of the time, the hosting company I use is in a different timezone to where I am. This tends to mess up things like the Date on the skin to the reporting dates for the website logs.
A major need for me was to make sure that entering a set of dates for a website log report would report on the days you requested. If the SQL Server is set to a different timezone to what your portal is, the results lose a lot of value, particularly when
analysing the traffic on a particular day, hour or day of week.
I worked out an easy fix for this - all you need to do is modify the dnn_SiteLogn
stored procedures which generate the site log reports.
The fix consists of running a stored procedure update. Note that this script was done for my database, which uses dnn_ as the standard object qualifier - you'd have to modify the script if you used a different one.
I expect that many other people run their portal in a different timezone to their host as well, and have found interpreting the site log reports a mental hurdle beyond the practical.
brchapman
Member
25 Points
5 Posts
Portal and Web/SQL Server on different timezones - curing the effects
Jun 07, 2006 01:11 AM|LINK
One problem I have with hosting my DNN websites is that, most of the time, the hosting company I use is in a different timezone to where I am. This tends to mess up things like the Date on the skin to the reporting dates for the website logs.
A major need for me was to make sure that entering a set of dates for a website log report would report on the days you requested. If the SQL Server is set to a different timezone to what your portal is, the results lose a lot of value, particularly when analysing the traffic on a particular day, hour or day of week.
I worked out an easy fix for this - all you need to do is modify the dnn_SiteLogn stored procedures which generate the site log reports.
Rather than re-type all the information again => it's in my blog at http://www.ifinity.com.au/Blogs/TechnicalBlog/tabid/307/EntryID/2/Default.aspx
The fix consists of running a stored procedure update. Note that this script was done for my database, which uses dnn_ as the standard object qualifier - you'd have to modify the script if you used a different one.
I expect that many other people run their portal in a different timezone to their host as well, and have found interpreting the site log reports a mental hurdle beyond the practical.
iFinitySmart Business Solutions