Prologika Forums

I bought your book and think its great. We have a WinForm app in VB VS2008 using the Report Viewer control (rdlc) which renders perfectly as long as we do not have a LiveMeeting or a IM Shared Desktop session active. The app executes SQL Server ad hoc queries, but the report viewer displays the animated rotating icon and never renders the report-- until we end the LiveMeeting Session. We googled around some but found no hits and MSDN seems silent on this also. Is this a known issue, and if so, are there attribute tweaks we can make to the ReportViewer control to avoid the issue? Or could this be a SQL Server ad hoc query issue/bandwidth/task priority issue-- that is unrelated to the ReportViewer control?

 Thanks for your help.

sam 

It's possible that the LiveMeeting session is changing your network stack. For issues like this, my first stop would be the SSRS trace log file to see if there are any error messages. Next, I'd use the RsRequestViewer sample I wrote (it's included in this download). You can use it to watch the client-report server traffic real time and see what calls ReportViewer makes to the server. If I find more info about this issue, I'll post it here.

I appologize. You mentioned rdlc. Hm, I don't know what could be wrong here since the report server is not involved at all. Could it be that your application is blocking? Can you use the SQL Server Profiler to see if the query actuall returns? I'll see if I can find more info.

Thanks for your reply; it gave me an idea for a test: (btw, SQL is returning data ok; its the refreshReport method that is hanging);  I understand from matt weber's comment at "that the rendering of the report all occurs on the primary thread.  If the report is small, this isn't a big deal, but if it is large then you can wind up with a blocked UI for a considerable period of time.  If you're hitting this problem with a large report, you will want to modify the code further to render the report on a background thread" (see http://blogs.msdn.com/mattweber/archive/2006/07/11/correcting-the-printed-margin-calculation-of-the-windows-forms-reportviewer-control.aspx)

So it looks like there is CPU contention between LiveMeeting who has monopolized the CPU and the RV who wants it; Therefore, i started a Live Meeting session and shared my desktop watching the cpu for PWConsole.exe in TaskManager climb very high: ca. 90%. Then i started the app and tried to render a report and nothing rendered. Then, i used Task Manager to reset the priority of PWConsole.exe to "LOW" and bumped the app to "HIGH"; then i tried rendering a report and it worked (as long as i also hit our custom refresh button that programatically does a refresh). This seems like a clumsy way to demo apps using the ReportViewer control with LiveMeeting, and may not be all that reliable overall--so maybe there is a better approach than this manual hack.

I appreciate any suggestions.

 sam

ReportViewer Windows Forms always processes the report on a background thread. Have you tried to repro the issue on another machine, such as duo core? As you said, it could be that the application is just starved from CPU. Can you execute something else that is processor-intensive while the LiveMeeting is running and see if it hangs as well?

Thanks for the suggestion. I wrote a quick little vb winform to gobble cpu so i could monitor the effect on LiveMeeting and various process priority changes. Its just an infinite loop that increments a counter and displays the sum in a text box; it peaks around 90% CPU. It seems that if LiveMeeting has a higher priority than the test app, the text box refresh crawls; lowering the process priority of LM (or raising that of the test app) causes the textbox refresh to spin. Duh. So can we conclude from this that ReportViewer is vulnerable to the same priority dynamics of any other cpu intensive app (and there therefore exhonerated from complicity)? Does this also mean the correct approach for  demonstrating apps running the reportViewer with LiveMeeting is to appropriately tweak the process priorities?

 Thanks again for the awesome suggestions!!

sam

I don't think that this issue is specific to ReportViewer.

>Does this also mean the correct approach for  demonstrating apps running the reportViewer with LiveMeeting is to appropriately tweak the process priorities?

My approach will be to remote to another box that has the ReportViewer demo and log a bug on connect.microsoft.com for LiveMeeting.

Thank you for the great idea: it works like a charm and makes perfect sense, a decision worthy of Solomon: in contention between two parties over a single resource, divide the resource and give each what they want. Remoting into another machine to run the demo relives the CPU contention from the mother machine running Live Meeting-- and everyone is happy.

Brillliant.

thanks again

sam