This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dev:odbc:home [2011/01/11 23:09] els created |
dev:odbc:home [2012/10/26 14:51] (current) |
||
|---|---|---|---|
| Line 4: | Line 4: | ||
| ====== Development: ODBC Interface ====== | ====== Development: ODBC Interface ====== | ||
| - | **[[dev:odbc:home|Overview]]** | [[dev:odbc:sample|ODBC Datasources]] | [[dev:odbc:sample|Sample Program]] | + | **[[dev:odbc:home|Overview]]** | [[dev:odbc:datasources|ODBC Datasources]] | [[dev:odbc:registering|Registering the Omnidex Driver]] | [[dev:odbc:sample|Sample C# Program]] | [[dev:odbc:examples:php_select | Sample PHP Program]] |
| ---- | ---- | ||
| Line 11: | Line 11: | ||
| ===== Overview ===== | ===== Overview ===== | ||
| - | The Omnidex ODBC driver is a compliant ODBC driver that provides ODBC access to Omnidex Environments. | + | The Omnidex ODBC Driver is a standard-compliant ODBC driver that provides ODBC access to Omnidex Environments. ODBC is most commonly found in a Microsoft Windows environment; however, it can also be found on UNIX platforms through available ODBC projects such as unixODBC. Omnidex's ODBC Driver is available on both Microsoft Windows and Linux operating systems. |
| - | Omnidex provides an ODBC driver for Windows client / server (any supported server) applications. The Omnidex ODBC driver is based on the SQL 2 standard, with most of the standard SQL functionality supported, as well as some additional, Omnidex specific, functionality. | + | The Omnidex ODBC Driver allows standardized access to Omnidex Environments from a multitude of third party tools and applications, such as Business Objects, Impromptu, MicroStrategy and Informatica. ODBC also provides access to common office tools, such as Microsoft Access, Excel and Word. Custom applications can also access Omnidex Environments using the standard ODBC API calls. |
| - | The Omnidex ODBC driver is used for applications using the ODBC CLI (Call Level Interface) with a variety of programming languages including C, C++, Visual Basic (ADO) and Cold Fusion. | + | The Omnidex ODBC Driver is based on the Version 2.0 of the ODBC standard. If you are using Version 3.5 of the ODBC standard, calls will automatically be downgraded to Version 2.0. |
| - | It is also used by third party container applications such as Cognos Impromptu, Seagate Crystal Reports, and Microsoft's Access, Excel, Word, and Query. | ||
| - | ==== Omnidex ODBC CLI ==== | + | ===== Integrating Omnidex with Third-Party Applications ===== |
| - | Microsoft's ODBC is a database-independent callable API suite originally developed to standardize database access on a Windows operating system. ODBC eliminated the need to write customer drivers for each database system and provided database vendors a means to support a broader range of application programs. | + | The Omnidex ODBC Driver allows easy integration with many third-party applications. Integration is usually as simple as providing the third-party application with an appropriate [[dev:connections:home|connection string]] to point to the existing Omnidex Environment. |
| - | The SQL/Call Level Interface (SQL/CLI) was developed using Microsoft's ODBC standard as a starting point, and modified to create an official ANSI/ISO standard. Microsoft has since devolved ODBC to conform to the official SQL/CLI standard, and expanded support to create ODBC/CLI, which has become a very widely supported standard. | + | Omnidex automatically optimizes SQL statements to provide the best performance. Nonetheless, there are times when the wording and structure of a SQL statement can affect performance. Each third-party application will use its own method of wording and structuring the SQL statement, and not all approaches generate the best performance. |
| - | Virtually all SQL-based database systems provide an ODBC/CLI interface as one of their supported interfaces, and some DBMS brands have adopted ODBC/CLI as their standard database API. | + | Some tools allow configuration options that alter the wording or structure of the SQL that they use. If you find that you are not obtaining satisfactory performance, you may be able to use these configuration options to improve the wording of the SQL statement, and therefore improve the performance. |
| - | Thousands of application programs support ODBC/CLI, including all of the leading programming tools packages, query- and forms-processing tools and report writers, and popular productivity software such as spreadsheets and graphics programs. | + | Omnidex is often used with third-party packages, but Omnidex is not regularly tested with each and every third-party package. If you have difficulty integrating Omnidex with a particular third-party package, please contact [[appendix:contactus|Technical Support]]. |
| - | + | ||
| - | ==== Call-Level Interface (CLI) Function Calls ==== | + | |
| - | + | ||
| - | The call-level interface (CLI) is a collection of application programming interface (API) calls developed for database access that use function calls to invoke dynamic SQL The important difference between the Omnidex ODBC CLI and the CLI developed by other database vendors is that the Omnidex ODBC CLI will work on any platform and against any database supported by Omnidex. It does not use the Microsoft Driver Manager and can, therefore, be used on a non-Windows machine like Unix or an HP3000 (HP3000 is no longer supported as of Omnidex version 4.0). | + | |
| - | + | ||
| - | Every Omnidex ODBC CLI application must begin by obtaining a handle for the environment and then a handle for the database connection. Memory is allocated for these handles and the information they store. A statement handle, used for processing SQL statements, will be obtained later in the application. Every subsequent CLI call will be passed one of these three handles. | + | |
| - | + | ||
| - | The environment handle must be the first handle established. It refers to the data object that contains global information about the current state of the application. The program allocates this handle by calling the SQLAllocEnv() CLI function call. Only one environment handle can be allocated per application, and it must be allocated before connection handles can be allocated. | + | |
| - | + | ||
| - | The connection handle must be established after the environment handle, but prior to any other CLI function calls. It refers to a data object that contains information associated with a database connection. This data object includes general status information and diagnostic information. The program allocates each connection handle by calling the SQLAllocConnect() CLI function call, and must allocate a connection handle for each connection it makes to a database server. These connection handles are then used to establish database connections and allocate SQL statement handles for use within those connections. | + | |
| - | + | ||
| - | The statement handles refers to a data object that contains information about an SQL statement. This data object includes information such as the SQL statement text, any dynamic SQL statement arguments, cursor information, bindings for dynamic SQL statement arguments and columns, result values, and status information. A program allocates a statement handle by calling the SQLAllocStmt() CLI function call; a statement handle must be allocated for an SQL statement before that SQL statement can be executed. Also, each allocated statement handle must be associated with a specific database connection handle. The maximum number of statement handles that can be allocated at any one time is limited only by the amount of available system resources (usually stack space). | + | |
| - | + | ||
| - | ==== Cursors ==== | + | |
| - | + | ||
| - | It is not necessary for an ODBC CLI application to implicitly open cursors. Each time the SQLAllocStmt method is called, the Omnidex ODBC driver calls oaopencursor. Each HSTMT object created with SQLAllocStmt, has its own cursor and should therefore, be considered a cursor itself. | + | |
| - | + | ||
| - | Switching between cursors is simply a matter of referring to the different HSTMT objects in the ODBC application. | + | |
| - | + | ||
| - | As noted above, it is not necessary for an ODBC CLI application to implicitly open cursors. However, it is possible to do so by using an OPEN CURSOR statement. The OPEN CURSOR statement is passed through an HSTMT object in the same manner as any SQL statement that does not return a result data set. | + | |
| - | + | ||
| - | To use a cursor that was opened implicitly through an OPEN CURSOR statement, a SQL statement must append an ON CURSOR n clause to the end of the statement. | + | |
| - | + | ||
| - | Use a CLOSE CURSOR statement to close cursors that were implicitly opened with the OPEN CURSOR statement. | + | |
| ===== ===== | ===== ===== | ||
| Line 61: | Line 36: | ||
| See also: | See also: | ||
| - | {{page>:dev:see_also:see_also&nofooter&noeditbtn}} | + | {{page>:dev:see_also&nofooter&noeditbtn}} |
| {{page>:bottom_add&nofooter&noeditbtn}} | {{page>:bottom_add&nofooter&noeditbtn}} | ||