ADO cursors

We have an issue with ado cursor In visual Cobol.   when we open a cursor with exec sql statement it fetch all rows in memory before returns to next statement. That means huge memory needs and alot of waiting time for the user. How can I make it work again like netxpress? The same in netxpress only opens the cursor without fetching any rows in memory umless you fetch the rows with fetch statement. 

  • Try setting the directive SQL(BEHAVIOR=UNOPTIMIZED) for compatibility with Net Express. This will turn off the autofetch feature.

    There are some other primitive directives under the main BEHAVIOR directive that you can use to fine-tune your performance. These are documented here:

    Thanks.

  • Thank you for the answer. That was our setting but I have found out that BEHAVIOR=MAINFRAME is the one that make our program works like before. The only difference is that until now we were setting the CONCURRENCY to OPTCC thru exec sql statement. Is there any difference in the way my application will work (with BEHAVIOR=MAINFRAME) regarding locks, updates etc.? Will be any changes for the end user (in a multiuser environment) concerning data retrieval/update. All our cursors are only for select. We have no cursors for update.

  • Thank you for the answer. That was our setting but I have found out that BEHAVIOR=MAINFRAME is the one that make our program works like before. The only difference is that until now we were setting the CONCURRENCY to OPTCC thru exec sql statement. Is there any difference in the way my application will work (with BEHAVIOR=MAINFRAME) regarding locks, updates etc.? Will be any changes for the end user (in a multiuser environment) concerning data retrieval/update. All our cursors are only for select. We have no cursors for update.

  • Thank you for the answer. That was our setting but I have found out that BEHAVIOR=MAINFRAME is the one that make our program works like before. The only difference is that until now we were setting the CONCURRENCY to OPTCC thru exec sql statement. Is there any difference in the way my application will work (with BEHAVIOR=MAINFRAME) regarding locks, updates etc.? Will be any changes for the end user (in a multiuser environment) concerning data retrieval/update. All our cursors are only for select. We have no cursors for update.

  • Verified Answer

    There is a difference internally in how cursors are handled when using ADO.NET instead of ODBC. If you have BEHAVIOUR=UNOPTIMIZED the cursor will be stored in an underlying Dataset.

    The actual behavior between MAINFRAME and UNOPTIMIZED if you are not using updateable cursors should not change except that you should experience better performance.

    The only incompatibility that I have seen that causes problems is that with MAINFRAME open cursors are closed whenever a COMMIT is done on the current transaction and with UNOPTIMIZED they are not. The workaround for this is to define the cursor using the WITH HOLD phrase.