Reply to thread

Message: [QUOTE="WenYuan Wang, post: 9505700"] Hi Cori, Thanks very much for your reply. I have consulted with our product team member. According to their subscription, I'm afraid it is not recommend you use ADO.net in Class ASP application. Additional, it is very hard to trouble-shot such issue. ADO.net dll library should only be used in .Net Framework application. Below is the reply from our product team. Please feel free to reply me if there is anything we can help with. You are welcome. Best regards, Wen Yuan =========================================================================== First, this is not an intended scenario for ADO.NET. Aside from that, even with managed ADO.NET code, I have seen this error occur in scenarios like you describe, where it doesn't seem to make sense. In each case, it was due to improper usage of the components, particularly multithreaded usage of components that do not support it. SqlConnection (all operations) and DataTable (write operations) are good examples of operations that are not threadsafe. With one particular customer, we were able to track down a scenario where multithreaded usage of SqlConnection was causing resultsets to get mixed up, so that what came back to the client on one request was actually the results for a different request that was being made on the same connection at the same time, for another thread. These are the kinds of things that can cause errors like you describe. It's difficult to track down these kinds of issues, although you can make an attempt from memory dumps taken a the point of the exception. Frequently that just shows you the aftermath of the problem, and doesn't help track down the root cause. Typically an architecture and code review will highlight general improper usage. In the case I mentioned above, the customer was storing a SqlCommand in ASP.NET session state. Once they changed this to use local SqlCommands whenever they needed one, their problems went away . Thanks, [/QUOTE]

Verification