>>I wasn't thinking of NOFILTER in terms of either performance or error reduction. I just seem to remember that if the query only produced a filtered result the cursor couldn't be passed back from the proc (but I might be wrong)
>
>The only way I could think presently to move in production with such a buggy provider would be to diminish the chances of having the errors.

Hmmmm, as long as the errors are always "showstoppers" generating real errors and not silently giving false info back, you could always loop until a query returns error free. I used a similar approach a few years back when every umpteenth "use" failed to set the specified alias - usually after a couple of heavy datacrunching hours. This was still in vfp6 without try-catch available, so based on the frequencies you cited I'ld loop the query until a dozen errors were reached in a row without a working call - that would probably some truly erroneos SQL - and your code heals the buggy OLEDB for you. Do the math: if you are incurring the an error every hundred calls, you can run a few millenia without incurring 12 such errors in a row from an otherwise "clean" SQL even on traffic much higher tan your estimates. Performance should not really be hurt, as try should be fast and only the catch incurs a meassurable lag, so the whole thing should be at less than 1.5% performance loss for 1% of errors ocurring on the calls <g>.

regards

thomas