I've been crunching .NET for about 6 days now (as in 18-20 hours per/day)
obliterating through the learning curve as fast as possible, with mostly
excellent success. I do have some trouble spots, one of which is a kicker
for me. I am writing a large application containing SQL2K, VB.NET, TCP and
a host of other internally related capabilities and Multi Threading is a
perfect technology to use on this one so I am. I have *thoroughly* read much
material on .NET Threading and currently/successfully spawn many different
types of worker threads (real world functions, not loops) that do what they're
told as intended and return with no instability issues, except *1* and it's
the pisser.

The Datagrid. Here's the scenario. I have fully configured SQL dataadapters
and datasets at the outset. My threaded sql ReturnDS function properly executes
and populates a specific-existing Dataset. oConfigSQL represents a Class
which inherits form. All adapters and datasets in question reside on this
form. When the code below is executed everything works like a champ, with
any number of successive calls to it. Logic exists elsewhere making sure
only *one* instance of this routine is executing at any given time. Also,
this is the current Test procedure and is a modified version of a more generic
one that is dataset-independent.

Public Shared Sub THREAD_ReturnDS()
With oConfigSQL.sqlCON_AllUsers
If .State = ConnectionState.Closed Then
End If
End With
With oConfigSQL.sqlDA_AllUsers
.Fill(oConfigSQL.DsAllUsers, 1, 1000, "tblUsers")
End With
Catch e As System.Exception
Console.WriteLine("ERROR INSIDE TESTER:" & Thread.CurrentThread.Name)
End Try
End Sub

The problem occurs when I have a Dagagrid on the form and have its datasource
as the dataset. With the datagrid set as specified the above routine still
never reports an error but after the dataset updates with the returned data
the program eventually crashes without a single error message. It simply
ends and returns to the IDE. The crash only occurs once message processing
for the window in which the datagrid exists begins again, as in dragging
the edges of the form to resize it. This seems to be the #1 quickest method
to reproduce the crash. I created a Class which inherits Datagrid and used
*this* instead. So now a datagrid is created from scratch and placed on the
form. This assisted in further issolation in combination with many other
things I've looked at. I can currently reproduce this seemingly uncatchable
exception with the click of a button. I can also *successfully* achieve the
original goal by reversing the order of 2 sequences. If I create the datagrid
*before* calling the ReturnDS (thus updating the existing dataset) the crash
is imminent. If I create it *after* ReturnDS everything works great and is
totally stable no matter what is done to the form size. This problem only
happens when ReturnDS is running from a spawned Thread.

What am I missing here? Why would the datagrid blowup? The Dataset has valid
structure at design-time and populates perfectly at runtime. All variations
used for creating the datagrid still amount to a public datagrid that is
unique, just brought into existence at different times. Is there something
wrong with the Datagrid and Multi-Threading or my code? I'm open to either
outcome. Just need to find out! ; )