Hi Michael

(started off on the wrong message...)

>>With the store procedure, I end up with the same result. I got an error after a few hundreds of transactions which is the same type of error I got before.
>
>Oh well. The only upside is that since the errors occur using a SPROC you have to ability to add some logging from within the VFP proc itself.

One of the things nagging me still is the feeling that somehow the intermediate cursors are getting trampled. In addition to Viv's hint about logging I'ld try a few more things with the SPROC :

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.

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

>Just to confirm: these errors are occurring when just running the basic aspx with a query returning a dataset? No framework, no other code in the global.asax ?

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

Hope I am sending you not off in too many blind alleys...

thomas