>>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.

procedure my_stored_proc
= sys(2336,1) && *-- define critical section start

*-- SPROC_ACTION, 
Select ...;


= sys(2336,2)  && *-- define critical section stop
return ...

>
>>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.

My train of thought was on the fact that OLEDB probably isn't often used *on the same machine* in multitasking/multithreading scenarios:
1) There are differences in caching behavior if many queries from different processes are run from one machine compared to several machines querying a living on a LAN-based table when using "normal" vfp.

2) When using vfp in connection with IIS like West-Wind or ActiveVfp they usually go for COM-servers in native mode, not via OLEDB. Is your desktop app running a) in several parallel processes on the same machine and b) querying via OLEDB ?

3) You could create some vfp-activeX-dataservers which do nothing but run a sql given as parameter via makroexpansion and return the result as XML, thus eliminating OLEDB. This is definitely NOT a technological reccommandation, more like a last resort while you wait for MS to fix the trouble with the OLEDB/iis/.net combo. Probably quite easier to implement into your existing application than switching to SQL server wholesale, giving you a solution NOW workable but less scalable and quite a hack <g>.

regards

thomas