Neil_Willby

Absent Member.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2011-11-28
17:11
1557 views
[Migrated content. Thread originally posted on 28 November 2011]
Hi,I use Visual Cobol and was just wondering if any one can advise if there any are advantages/disadvantages to setting the OpenESQL Assistant Mode to :-
1) ODBC
or
2) ADO.NET
Thanks
Neil.
1 Solution
Accepted Solutions
Chris Glazier

Micro Focus Expert
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2011-11-28
17:21
The options in OpenESQL Assistant only refer to the syntax of the COBOL code that you would like to generate.
The compile directive SQL(DBMAN=ODBC) or SQL(DBMAN=ADO) refer to the underlying code that will be generated by the OpenESQL preprocessor.
If you specify ODBC then the underlying code will be generated to communicate with a specified ODBC driver using the DSN setup under the Windows ODBC Administrator.
If you specify ADO for managed code then the underlying code will be generated to communicate with a specified ADO.NET Data Provider such as SQL Server Native Client or Oracle ODP.NET.
If you are using native code then ODBC is the only option that you can use.
If you are using managed code and your database vendor has an ADO.NET Provider then you can use the DBMAN=ADO directive.
In addition to supporting the standard EXEC SQL statements supported by ODBC, you can also use EXEC ADO statements which allow you to work directly with ADO.NET objects such as Datasets and Tables. These objects support syntax for both connected model and disconnected model statements so that you can define ADO tables and Datasets that can be stored completely in-memory without the need for a physical database on disk.
This makes binding to GUI objects such as Grids and ListViews easy as you can bing the table or dataset directly to the .NET objects.
You can also share Connection objects and Dataset objects with programs written in other .NET languages such as C# or VB.NET.
If you are using managed code and your database supports it then you should use ADO in preference to ODBC as it was designed specifically for .NET applications.
For a list of EXEC ADO statements that are supported please see:
EXEC ADO Statements
The compile directive SQL(DBMAN=ODBC) or SQL(DBMAN=ADO) refer to the underlying code that will be generated by the OpenESQL preprocessor.
If you specify ODBC then the underlying code will be generated to communicate with a specified ODBC driver using the DSN setup under the Windows ODBC Administrator.
If you specify ADO for managed code then the underlying code will be generated to communicate with a specified ADO.NET Data Provider such as SQL Server Native Client or Oracle ODP.NET.
If you are using native code then ODBC is the only option that you can use.
If you are using managed code and your database vendor has an ADO.NET Provider then you can use the DBMAN=ADO directive.
In addition to supporting the standard EXEC SQL statements supported by ODBC, you can also use EXEC ADO statements which allow you to work directly with ADO.NET objects such as Datasets and Tables. These objects support syntax for both connected model and disconnected model statements so that you can define ADO tables and Datasets that can be stored completely in-memory without the need for a physical database on disk.
This makes binding to GUI objects such as Grids and ListViews easy as you can bing the table or dataset directly to the .NET objects.
You can also share Connection objects and Dataset objects with programs written in other .NET languages such as C# or VB.NET.
If you are using managed code and your database supports it then you should use ADO in preference to ODBC as it was designed specifically for .NET applications.
For a list of EXEC ADO statements that are supported please see:
EXEC ADO Statements
2 Replies
Chris Glazier

Micro Focus Expert
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2011-11-28
17:21
The options in OpenESQL Assistant only refer to the syntax of the COBOL code that you would like to generate.
The compile directive SQL(DBMAN=ODBC) or SQL(DBMAN=ADO) refer to the underlying code that will be generated by the OpenESQL preprocessor.
If you specify ODBC then the underlying code will be generated to communicate with a specified ODBC driver using the DSN setup under the Windows ODBC Administrator.
If you specify ADO for managed code then the underlying code will be generated to communicate with a specified ADO.NET Data Provider such as SQL Server Native Client or Oracle ODP.NET.
If you are using native code then ODBC is the only option that you can use.
If you are using managed code and your database vendor has an ADO.NET Provider then you can use the DBMAN=ADO directive.
In addition to supporting the standard EXEC SQL statements supported by ODBC, you can also use EXEC ADO statements which allow you to work directly with ADO.NET objects such as Datasets and Tables. These objects support syntax for both connected model and disconnected model statements so that you can define ADO tables and Datasets that can be stored completely in-memory without the need for a physical database on disk.
This makes binding to GUI objects such as Grids and ListViews easy as you can bing the table or dataset directly to the .NET objects.
You can also share Connection objects and Dataset objects with programs written in other .NET languages such as C# or VB.NET.
If you are using managed code and your database supports it then you should use ADO in preference to ODBC as it was designed specifically for .NET applications.
For a list of EXEC ADO statements that are supported please see:
EXEC ADO Statements
The compile directive SQL(DBMAN=ODBC) or SQL(DBMAN=ADO) refer to the underlying code that will be generated by the OpenESQL preprocessor.
If you specify ODBC then the underlying code will be generated to communicate with a specified ODBC driver using the DSN setup under the Windows ODBC Administrator.
If you specify ADO for managed code then the underlying code will be generated to communicate with a specified ADO.NET Data Provider such as SQL Server Native Client or Oracle ODP.NET.
If you are using native code then ODBC is the only option that you can use.
If you are using managed code and your database vendor has an ADO.NET Provider then you can use the DBMAN=ADO directive.
In addition to supporting the standard EXEC SQL statements supported by ODBC, you can also use EXEC ADO statements which allow you to work directly with ADO.NET objects such as Datasets and Tables. These objects support syntax for both connected model and disconnected model statements so that you can define ADO tables and Datasets that can be stored completely in-memory without the need for a physical database on disk.
This makes binding to GUI objects such as Grids and ListViews easy as you can bing the table or dataset directly to the .NET objects.
You can also share Connection objects and Dataset objects with programs written in other .NET languages such as C# or VB.NET.
If you are using managed code and your database supports it then you should use ADO in preference to ODBC as it was designed specifically for .NET applications.
For a list of EXEC ADO statements that are supported please see:
EXEC ADO Statements
Neil_Willby

Absent Member.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2011-11-28
20:53
Hi Chris,
Thanks for info.
I use the ODBC mode and because my databases are now getting quite large are there any tricks/tips to make retrieving data faster from the SQL database?
Kind regards
Neil.
Thanks for info.
I use the ODBC mode and because my databases are now getting quite large are there any tricks/tips to make retrieving data faster from the SQL database?
Kind regards
Neil.