[Erlang Systems]

4 Overview

4.1 Interfaces

The interface of the Erlang ODBC application divided into four parts:

An ODBC serving process can be compared to an Erlang port. It allows you to make function calls, from Erlang, to an ODBC Driver (or in reality a Driver Manager, which talks to a Driver). The Driver communicates with the database, which it is built for. The serving process also plays the role of a server and will be referred to as the server in this text.

When you start ODBC you get a new server, which handles requests by passing them on to an ODBC Driver. Requests are handled sequentially and the server cannot be connected to more than one database at any time.

Note!

An ODBC server can only be started on a named node with a cookie (start Erlang with one of the -name <nodename> or -sname <nodename> options and possibly with the -setcookie <cookie> option).

The server links to the process that starts it (the client). Should the client terminate, the server terminates too. The server is dedicated to the client process just like an Erlang port, but there are two important differences: an ODBC server accepts requests from any process (ports accept messages from the connected process only), and it does not send messages spontaneously (or deliver them from the ODBC Driver) -- the ODBC server is passive.

4.1.1 Utility API

Using the Utility API is easy. Follow the steps below:

  1. Start the server by calling start_link/[2, 3] .

  2. Connect to the database with one of erl_connect/[2, 3, 4, 5]

  3. Submit SQL statements to the database by calling erl_executeStmt/[2, 3].

  4. Disconnect by calling erl_disconnect/[1, 2]. At this point it is possible to connect to another database by calling erl_connect/[2, 3, 4, 5] again.

  5. The server process dies when stop/[1, 2] is called.

4.1.2 Basic API

To be able to make full use of the Basic API it is necessary to be familiar with the ODBC standard. Here is a typical way to use it for a SELECT statement though:

  1. Connect to the database: sqlConnect/[4, 5].

  2. Execute an SQL statement: sqlExecDirect/[2, 3]

  3. Check how many columns the SQL statement returns from database with sqlNumResultCols/[1, 2].

  4. Create a reference for column: columnRef/0.

  5. Bind the reference to the column: sqlBindCol/[3, 4].

  6. Repeat the last two steps for each desired column (not necessarily all columns in the table).

  7. Get the data for the columns: sqlFetch/[1, 2].

  8. Get the data for a column: getData/[2, 3].

  9. Repeat the last step for each selected columns.

  10. Repeat the last tree steps until all rows in the table have been retrieved or sqlFetch returns ?SQL_NO_DATA.

  11. Close the handler: sqlCloseHandle/[1, 2].

  12. Start over with step 2 to execute a new statement.

  13. Disconnect from the database: sqlDisConnect/[1, 2].

You may use the Basic API and the Utility API intermittently, but remember that certain operations performed in the Basic API (like setting different attributes defined by the ODBC standard) may affect the behaviour of the Utility API.

4.1.3 Choice of API

When to use which API? The Utility API can be used when none of the following is true:


Copyright © 1991-2002 Ericsson Utvecklings AB