Transition from COM context error in WPF when fetching large amount of data from SQL

Question

I am working on wpf application. This application is used to show the reports. For this I have two tabs: one tab to select the columns from listview and other filters, the second tab shows the result from sql table. Here for dynamic query I am making a query on server side and pass this in stored procedure as parameter there I am executing it using execute method.

Problem :

It works fine if I select some columns out of total 170, but when I select all columns in list view and try to go on other tab it remains on the same tab and throws the exception:

The CLR has been unable to transition from COM context 0xc40048 to COM context
0xc401b8 for 60 seconds. 

there is thousands of rows fetch for this.

Question :

1.)how i can make execution fast for query.

2.)Steps to make table more fast for fatching data.

Answer 1

A few ideas:

• Use BackgroundWorker class and work with the Dispatcher in WPF.
• Page the results - you could also create the infinite scroll effect
• Use DataReader instead of DataSet
• Hide/disable rendering of the control on Tab 2, bind the data, re-enable control. In WinForms, you'd use SuspendLayout / ResumeLayout
• Change the UI - I can't imagine how a human can process 170 columns ... perhaps there is a even better (often simpler) presentation of the data you can provide

Ultimately, you need to determine where in your call stack the performance problem is. The Visual Studio debugger should help with this, but you may need to use some other tools. Use SQL Profiler to analyze your Stored Procedure/SQL Server behavior. For the network connection, try something like WireShark.

EDIT: added Dispatch/BackgroundWorker link --- you still need to know where the timeout is occurring.

Answer 2

The contextSwitchDeadlock managed debugging assistant (MDA) is activated when a deadlock is detected during an attempted COM context transition.

Symptoms

The most common symptom is that a call on an unmanaged COM component from managed code does not return. Another symptom is memory usage increasing over time.

Cause

The most probable cause is that a single-threaded apartment (STA) thread is not pumping messages. The STA thread is either waiting without pumping messages or is performing lengthy operations and is not allowing the message queue to pump.

Memory usage increasing over time is caused by the finalizer thread attempting to call Release on an unmanaged COM component and that component is not returning. This prevents the finalizer from reclaiming other objects.

By default, the threading model for the main thread of Visual Basic console applications is STA. This MDA is activated if an STA thread uses COM interoperability either directly or indirectly through the common language runtime or a third-party control. To avoid activating this MDA in a Visual Basic console application, apply the MTAThreadAttribute attribute to the main method or modify the application to pump messages.

It is possible for this MDA to be falsely activated when all of the following conditions are met:

· An application creates COM components from STA threads either directly or indirectly through libraries.

· The application was stopped in the debugger and the user either continued the application or performed a step operation.

· Unmanaged debugging is not enabled.

To determine if the MDA is being falsely activated, disable all breakpoints, restart the application, and allow it to run without stopping. If the MDA is not activated, it is likely the initial activation was false. In this case, disable the MDA to avoid interference with the debugging session.

Resolution

Follow COM rules regarding STA message pumping.

To avoid these error popups from appearing, select Exceptions from the Debug menu from Visual Studio window and in the Exception Dialog box select the Managed Debugging Assistants Exception Node. Then select ContextSwitchDeadlock and remove the select from Thrown column.

How to make execution fast:

There are many ways to do it

Create the missing index on table.

Create indexed view on this table.

You can also partition the table on basis of data range.

Put this table on other disk so data read/write will be fast.

Answer 3

Well, if you want to make your database calls more efficient, I suggest you try out the Enterprise Library, the current version is 5.0. Worked well with our application.

http://msdn.microsoft.com/en-us/library/ff648951.aspx

Answer 4

Personally I suggest that you filter the results at the SQL level instead of in the application itself, although there are several answers here that will also improve your performance on the application side and they should be followed.

For sample code to use SQL paging see T-SQL: Paging with ROW_NUMBER().