Highlighted
Absent Member.
Absent Member.
1873 views

ADO cursors

Jump to solution

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. 

0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

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.

View solution in original post

0 Likes
3 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

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.

0 Likes
Highlighted
Absent Member.
Absent Member.

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.

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

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.

View solution in original post

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.