>>I've been thinking of the performance implications a bit. Dropping to 4 seems to allow for errors to crop up sometime and setting it higher won't hurt performance overall as long as the errorlevel stays at a low percentage.
>>
>>As this handles about 95% of your total SQL, having the critical insert/update/delete run slower might be ok if the changes are not too great (allowing for a quick port back if the issue is resolved).
>>
>>If I understood ASP.Net Side-by-Side correctly, you cannot force different runtimes directly inside a ASP.Net-process:
>>
>>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconaspnetside-by-sideoverview.asp
>>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpcondeterminingwhatversionofruntimetoload.asp
>>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconconfiguringassemblybindingredirection.asp
>>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconmanagingmultipleversionsofaspnet.asp
>>
>>but I have not seen any clear indication if it is totally impossible to call up a .net 1.1 dll wrapped inside a COM-interface either directly or indirectly or perhaps only in/through another process from ASP.NET 2.0. IF the problem lies in the communication between .net 2.0 and OLEDB, using the OLEDB-Adapter wrapped inside a .Net 1.1-hosted DLL might stop the errors for those critical 5% while keeping the speed of for the other 95% using the errorchecking. The worst case scenario from a perfromance point of view would be to replace your .net2 OleAdapter with a call to a vfp.exe or C/C++.Exe calling up a .net 1.1 OleAdapter - but as this happens only in those 5 percent perhaps not crippling, if it works.
>>
>>As only the OleDbAdapter would be used in the .Net 1.1 - level the changes should not be too drastic. Be sure to read up before trying, this is something I only read about and have no practical expirience! I might have misunderstood the docs...
>
>I have a lot of things that might not be workable under 1.1. I am not sure if this would apply to such an approach.

Not sure if I made myself clear: I was NOT talking about running all insert/update/delete pages directly under 1.1 (which would be a technical possibility if you hadn't used any 2.0 niceties from what I understand) but to call OLEDB with an isolating COM wrapper to force ONLY the OleDbAdapter-class to work within 1.1. All your other code could use .Net 2.0. And I was hoping to learn a bit more by letting others do the grunt work <g>.

>But yes, there is definitely a corelation between .NET 2.0 and the OleDb provider. I think we can say we have isolated the bug within those conditions. But, again, only with the IIS environment. As, under the desktop environment, we were never able to simulate that.

Which is one of the reasons I am still suspecting some caching mechanism.

regards

thomas