mydataadapter.fill

I have a 2003 program that opens a foxpro table via odbc and loads in
the data into a dataset. I copied the code into a 2005 program after a
long wait it fails with the error

ContextSwitchDeadlock was detected
The CLR has been unable to transition from COM context 0x1a3008 to COM
context 0x1a3178 for 60 seconds. The thread that owns the destination
context/apartment is most likely either doing a non pumping wait or
processing a very long running operation without pumping Windows
messages. This situation generally has a negative performance impact and
may even lead to the application becoming non responsive or memory usage
accumulating continually over time. To avoid this problem, all single
threaded apartment (STA) threads should use pumping wait primitives
(such as CoWaitForMultipleHandles) and routinely pump messages during
long running operations.

I changed my fill statement from myDataAdapter.Fill(ds, tableName) to
myDataAdapter.Fill(ds, 0, 50, tableName) and that works great but I
want all the records.

What's up?

Hi cj,

This is caused by the ContextSwitchDeadlock managed debugging assistant
(MDA) (http://msdn2.microsoft.com/en-us/library/ms172233.aspx), which is a
new feature in VS2005.

The MDA works to detect deadlock with a pre-defined timeout, and it's only
effective when you're running the program under debugger. To turn off this,
plesae add following content to your application configuration file:

<mdaConfig>
<assistants>
<contextSwitchDeadlock enable="false" />
</assistants>
</mdaConfig>


Or you can use following steps to turn off this MDA globally:

1) Open your project in Visual Studio 2005
2) Click on the Debug menu on the main menu of the Visual Studio IDE.
3) Choose the Exceptions option (Debug -Exceptions).
4) The Exceptions window will open.
5) Expand the "Managed Debugging Assistants" node.
6) Uncheck the ContextSwitchDeadlock option under the Thrown column.
7) Click on Ok and close the Exceptions window. You can now run your
application
and test it to see whether the exception occurs again.


Hope this helps.


Regards,
Walter Wang (wawang@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

That worked. It takes quite a bit longer than 2003 however. Both are
running in debugging mode. Maybe 2005 has more code to execute in
debugging mode than 2003. Perhaps I should test that theory.


Walter Wang [MSFT] wrote:

I did some testing. I compiled the program in 2003 and 2005. The 2003
program takes 45 seconds to load the data and the 2005 program takes 1
minute and 40 seconds to load the data. That a whole minute longer!
Why do you reckon this is?


Walter Wang [MSFT] wrote:

Just happened to think. Was the time for loading the records into the
dataset or from dataset to grid? So I tested again timing only the time
it took to load the records into a dataset. 2003 was 42 seconds. 2005
50 seconds. Very consistent over about 3 tries. So it looks like using
the new datagridview

DataGridView1.DataSource = ds
DataGridView1.DataMember = tableName

takes much longer than using the old datagrid

DataGrid1.SetDataBinding(ds, tableName)

DataGridView takes about 55 seconds while datagrid one 3 seconds. Can
anyone comment on this?

cj wrote:

Hi cj,

This is unfortunately a known issue of DataGridView:

https://connect.microsoft.com/Visual...ck.aspx?Feedba
ckID=117093

<quote>
The big difference between the DataGrid and the DataGridView is that the
DataGrid uses Graphics.DrawString(text, font, brush, textBounds, format)
while the DataGridView uses TextRenderer.DrawText(graphics, text, font,
textBounds, color, flags). This is where the biggest difference comes from
in my opinion.
</quote>

You can vote on the issue, this will increase the priority of the issue in
our future improvement plan. Thanks.

Regards,
Walter Wang (wawang@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Well, at least that's an answer. I decided to find out if I could use
the old datagrid in 2005 so I copied my 2003 program to a new dir and
upgraded it to 2005. It kept the datagrid instead of using
datagridview. However performance was 1 minute and 40 seconds on the
upgraded project vs 45 seconds when it was compiled in 2003. So I guess
even if I use the old datagrid in 2005 I will still not get any faster
performance. This sucks. The shame of it all was that 45 seconds was
determined to be too slow so the program was written in Visual FoxPro
instead of 2003. I had hoped 2005 would be faster and able to compete
with FoxPro on this type of app as it occurs here quite often.

I consider myself more of a VB programmer than a FoxPro programmer so
it's humiliating to me to have these problems. I'm not going to get
into a debate about how good VB or Foxpro is. That isn't the point.
The point is I'm disappointed in VB's performance and frankly complexity
too especially in this area. The FoxPro app which turns out a
strikingly similar screen comes up with the data being display in less
than 5 seconds. I can't compete with that using VB! Admittedly it has
the home court advantage as the data is in a stand alone FoxPro table
but all I had to do was put the grid on the form and tell it the
datasource was the table and it was done. I really wish MS would
include in VB the ability to use FoxPro stand alone tables--call it
something else if they wish but that kind of simple functionality. They
own both languages how hard could it be?

Walter Wang [MSFT] wrote:

Hi cj,

I understand your concerns about the performance issue regarding
DataGrid/DataGridView in VS2005. Thanks for the feedback. I'll make sure
they're are passed along to product team.

Regards,
Walter Wang (wawang@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Thanks, and thanks for the help.

Walter Wang [MSFT] wrote: