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.
ADO cursors
+2- Moderator
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.
- Rocketeer
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.
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.
- Rocketeer
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.
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.
- Rocketeer
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.
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.
+2- Moderator
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.
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.
Recent badge winners
Sign up
Already have an account? Login
Welcome to the Rocket Forum!
Please log in or register:
Employee Login | Registration Member Login | RegistrationEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.
77 4th Avenue
Waltham, MA 02451 USA
