>1) make the SPROC approach one totally encapsulated with no parameters at all for debugging at first, Just a call to SPROC (with necessary filter info in constants for instance) should generate the error in a reasonable amount of time with a minimum of code/joins to make experimentation easier.

Yes, this was the approach I use for the test.

>2) bracket the whole thing with calls to sys(2336,1), SPROC_ACTION, sys(2336,2).
> This is just to scratch the above itch.

I am not sure what you mean here.

>3) to make sure the problem is with OLEDB across the board and not some problem with .net I'ld build a simple vfp prg calling those SPROC queries via OLEDB from several vfp-instances/Exes with the same frequnecies incurring the error. This may seem unneccesary from your POV since you need the backend to work from your .net code, but everything isolating the error helps enormously. If the error is reproducible with vfp and OLEDB you might get more input/help from the vfp side of UT - and if the error only surfaces using .Net you might ring other bells <bg>.

I never got this situation in desktop application. I only have it under the IIS environment. Earlier on, I think I mentioned something about that. This provider is buggy under the IIS and/or the .NET thing. So, it is related within those conditions. My robot application is firing a lot of SQLs and I never got it in 6 months. Nor did I ever got an error from a desktop application about such an unexplained error message as well. As for the Web site, the chances of getting more errors was when firing a lot of hits. But, when I first discovered that or on an occasional basis, this is happening with situation that no traffic at all is present on the server but only one hit. It is just that it takes more time to have the error as there is less chance to have it if less traffic is generated.