Yes, 2.0 has "new and improved" async handling for the query-portion of the
query execution. The fetch portion is still up to you to handle. Can this be
done reliably in 1.1? I've done it... but reliability or scalability is
harder. If you over-stress the server or the client system with too many
operations, you can also generate errors that would not ordinarily occur.
Each connection can support one (and only one) DataReader at a time. If you
enable MARS you can execute more but I would investigate this thoroughly
first (I don't recommend MARS). These "general network" errors can occur if
the networking layers get disconnected or confused. They're also caused by
hardware disruptions.
hth
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
"Valerie Hough" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thank you for your reply. Each thread that is created creates a new
> SqlConnection object, a new SqlCommand object, and then does
> SqlCommand.ExecuteReader(). I'm not sure if this is the 'same'
> SqlDataReader or not. Please let me know, and, if it is, could you
> possibly suggest any article that would describe how to serialize the
> access among threads.
> Also, does it matter whether my thread is declared as static or not, and
> whether it uses the SingleThreaded Apartment model or the MultiThreaded
> one?
> Thank you in advance for your help.
>
> "Lale Divringi [MSFT]" <(E-Mail Removed)> wrote in message
> news:ek$(E-Mail Removed)...
>> SqlDataReader is not designed for multi-threaded access. You cannot read
>> from the same SqlDataReader object through multiple threads without
>> serializing the access to this object among the threads.
>>
>> Thanx
>> Lale Divringi
>>
>> DISCLAIMER: This posting is provided "AS IS" with no warranties, and
>> confers no rights.
>>
>> "Valerie Hough" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> Hi,
>>> I am debugging an application which uses C# with .NET v1.1. It attempts
>>> to implement asynchronous dataset retrieval by using separate threads
>>> and synchronizing them with the UI form. Recently the application is
>>> having some problems whereby it is crashing with a "General Network
>>> Error" and a call stack that looks approximately like this:
>>>
>>> System.Data.SqlClient.SqlDataReader.TdsParser.ThrowExceptionAndWarning()
>>> System.Data.SqlClient.SqlDataReader.TdsParser.ReadNetLib(...)
>>> System.Data.SqlClient.SqlDataReader.TdsParser.ReadBuffer(...)
>>> System.Data.SqlClient.SqlDataReader.TdsParser.ReadByteArray(...)
>>> System.Data.SqlClient.SqlDataReader.TdsParser.ReadEncodingChar(...)
>>> System.Data.SqlClient.SqlDataReader.TdsParser.ReadValue(...)
>>> System.Data.SqlClient.SqlDataReader.TdsParser.ProcessRow(...)
>>> System.Data.SqlClient.SqlDataReader.PrepareRecord(int32)
>>> System.Data.SqlClient.SqlDataReader.GetValues(Object [] values)
>>> AsynchronousReadDataThread()
>>>
>>> Notes:
>>> - In the form application, Thread.Join() is used if the dataset read is
>>> not complete.
>>> - There might be 10-20 threads reading at any given point in time.
>>> - It is a hit and miss type of problem that only seems to occur with
>>> heavy usage across several CPUs.
>>>
>>> Does anyone know what the cause of this might be?
>>> Are these read threads safe if they happen to be executing views that
>>> might join some of the same tables as one another?
>>> Assuming that the asynchronous reading is necessary, is this approach
>>> conceptually sound?
>>> I see that .NET 2.0 is just released with support for this sort of thing
>>> built in. Do I need VS 2005 to incorporate it into apps?
>>>
>>> Thanks in advance for any help.
>>> Valerie Hough
>>>
>>
>>
>
>
Similar Threads
