Hi, I have an issue with all reports that use date/time parameters that has only recently started this Tuesday in fact, and it seems to affect all versions of IE 7-9 and XP and Windows 7. Other browsers don't have this problem, chrome and fire fox are fine. When loading a report that uses these parameters, it is running the processor up to 100% on the client machine and takes forever to load, on under powered boxes it can literally takes minutes to load, these reports ran before in seconds. The date/time parameters have default values like =DateAdd("d", -1, Today()) and are usually representing a range of dates From: and To:. After the report finishes loading, changing either date field whether with the calendar control or manually typing the date causes this delay again. The page freezes and becomes unresponsive, the client machines processor is maxed out. Even after the report refreshes or reloads, for a period of another 20 to 45 seconds the page is still unresponsive. Changing the date/time parameter to a string, while maintaining the above default values, thus ridding the calendar control and the reports load and behave just like prior to last Tuesday. I have no updates on my machine from Microsoft, the other client machines do not either, the server that houses reporting services has not received any updates either during the time frame that this issue started. These reports have been on the server and have not been updated in a while, so there was not a change to those. Any ideas on what might be causing this issue. It's made RS almost unusable for many users. Thanks

An Addendum to my post above with additional information. Both the server and client machines have been re-booted to no affect. I also have a report where I monitor rendering time of all reports, including data retrieval etc.. In the last one week it is reporting no difference in the amount of time it is taking to retrieve data and render the report, which leads me to believe it's client side, but I'm not for sure.

HI Captain ! Lets try to clear the Client Cache using "Ctrl + F5" and see if this works. Also try to add Report Manager URL to trusted site. Please let me know if this helps. Hopefully i have answered you correctly. Thanks, Hasham Niaz

I've tried both suggestions of clearing the cache and adding it to trusted sites, neither resolved it , the symptoms above are still the same. Thanks.

An update after further testing today... I can leave the parameters as Date/Time with default parameters set and so long as I set the parameters to hidden the reports run fine, fast as usual. This leads me to believe it is related to the date picker control loading, I'm specualting but with the above testing that's the only difference. Also tested 2 laptops that were not on the network when the problems started last week, one XP and the other Windows 7. Both ran reports with date parameters and the date picker control flawlessly. I've asked the network admin about any updates that might have been pushed, again looking at the client machines I can not see that any updates have been pushed in quite a while, he's checking into it, and beleives none have been. Is anybody aware of any updates that might cause this problem? Could Group Policy affect this? Thanks for considering this...

Hi Mightycaptain, Does the report run fine in Business Intelligence Development Studio environment? In Reporting Services, we can monitor report execution performance using execution logs, Here are some articles for your reference, please see: Reporting Services Log Files: http://msdn.microsoft.com/en-us/library/ms157403(v=sql.90).aspx In addition, I found an good article about Reporting Services Performance Optimizations. You can take a look at it, especially "Tuning the Web Service" section. Please see: Reporting Services Performance Optimizations: http://sqlcat.com/sqlcat/b/technicalnotes/archive/2009/01/14/reporting-services-performance-optimizations.aspx Thanks, Bin LongBin Long TechNet Community Support

Bin Long, That you for your reply. It runs fine in BIDS. I have also examined the execution logs, everything there is fine, it is the same from before and after this problem started. Stored Procedure Execution Time, and Report Rendering are all very fast normally. I have done some additional testing of this issue. The problem causing this delay on the client machines appears to Symantec Endpoint Protection. If this is disabled, the reports run fine. In addition, I also discovered that adding an exception for .htm file extensions in Symantec allowed me to leave the program enabled and still allowed the reports with Date/Time Pickers to run fine. A step further in testing revealed that the hangup is occurring on the Reserved.ReportViewerWebControl.axd? (etc...) .htm that is downloaded to the Temporary Internet Files in the user folder when a date time parameter is changed or loaded and the report is ran or re-ran. So I could also add a File exception to Symantec for a particular users Temp Internet Folder and that returned reports to normal operations as well. So where I'm stumped now, is what is in that file that Symantec protests but then allows to download and run anyways albeit very slowly? Adding an exception for .js or ReportServer.js does not resolve this issue. You can't add an exception for a file in this case because Symantec doesn't allow the use of wildcards for File Names and the name of this files changes with each report and parameter change. I realize that now this issue may be flirting with needing to be posted in a different forum altogether, but if anyone has any insight into this I would be grateful Thanks, MightycaptainMightycaptain

Hi Mightycapation, It seems this issue caused by Symantec Endpoint Protection. I recommand you trun off the antivirus software to see if the report works fine. The Symantec Endpoint Protection is third-part software, if you any questions about it, please post the questions in Endpoint Protection forum: http://www.symantec.com/connect/security/forums/endpoint-protection-antivirus Thanks for your understanding. Regards, Bin LongBin Long TechNet Community Support

Hi Mightycapation, It seems this issue caused by Symantec Endpoint Protection. I recommand you trun off the antivirus software to see if the report works fine. The Symantec Endpoint Protection is third-part software, if you any questions about it, please post the questions in Endpoint Protection forum: http://www.symantec.com/connect/security/forums/endpoint-protection-antivirus Thanks for your understanding. Regards, Bin LongBin Long TechNet Community Support

Bin Long It is caused completely by Symantec Endpoint Protection. I can turn it off or uninstall and it completely resolves this issue or add the extension htm as an extension Exception for File Protect resolves it as well. Thank you for the link I will post there for a resolve, if a solution is found, I will post it back here. We can't be the only people that are going to see this issue I wouldn't think. Thank you for considering, MightycaptainMightycaptain

Hi All, We appear to be having the same problem as well.

I have posted on the Symantec Forums and am awaiting some feedback. I will post back to this thread with any replies or solutions that I recieve. This is a very frustrating issue. MightycaptainMightycaptain

Thank you Mightycaptain!!!

I thought I would update and include a link to my post on Symantec. No real solution other than the work arounds I stated above, though it for sure looks like that others are seeing this issue and some have started a support case with Symantec. http://www.symantec.com/connect/forums/sql-reporting-2005-calendar-control-issuesymantec-endpoint-file-protect MightycaptainMightycaptain

Final update: This issue for us at least has resolved it's self in the last 24 hours with one of the definition updates from Symantec. See the post above for the a link to the thread on the Symantec website. One of the responses I got there by someone testing had discovered a potential resolve, that couldn't be fully tested as the issue for him resolved it's self as well, I would assume with a definition update too, if this occurs again though, that is the first thing I'm going to try. Thank you for all the replies. MightycaptainMightycaptain