If you are able to pre-generate the pages, then maybe caching the pages would be an option instead?

Maybe add something like this to the top of your page:

< %@ OutputCache Duration="60" VaryByParam="*" % >

>>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. That could be done by taking my two busiest pages and turning the reception of them into the robot application which would generate pre-generated pages about all the records available in those two page related tables. I would have the robot to generate all that every hour. That would represent about 100 pages in French and English for the first page and about 20 new pages in French and English for the second page. Each of those pages are generating about 20 SQLs each. So, this will diminish the amount of errors. That would represent a lot of work to do and maintenance. But, I just can't see anything else presently. Using that approach, I would be able to either store the HTML on disk and pull it out from the top of the code that generate those pages presently and simply return instead of proceeding with the regular code. Or, I would be able to
>simply store that HTML code in memo fields by adding two memo fields (English and French) in both tables and simply do one SQL to get the pre-generated HTML from there. At least, doing that would avoid me to manage a lot of files on disk which would create a lot of collisions in such circumstances based on the number of occurences for the creation of those pages. But, I would still get the errors. As, presently, I get some of them when there is only one SQL in a page.