If you need to access a relational database such as
The Erlang ODBC application should work for any relational
database that has an ODBC driver. But currently it is only
regularly tested for
The Erlang ODBC interface is in principal database
independent, e.i. an erlang program using the interface could be
run without changes towards different databases. But as SQL is
used it is alas possible to write database dependent
programs. Even though SQL is an ANSI-standard meant to be
database independent, different databases have proprietary
extensions to SQL defining their own data types. If you keep to
the ANSI data types you will minimize the problem. But
unfortunately there is no guarantee that all databases actually
treats the ANSI data types equivalently. For instance an
installation of
Another obstacle is that some drivers do not support scrollable
cursors which has the effect that the only way to traverse the
result set is sequentially, with next, from the first row to the
last, and once you pass a row you can not go back. This means
that some functions in the interface will not work together with
certain drivers. A similar problem is that not all drivers
support "row count" for select queries, hence resulting in that
the function
The following is a list of the ANSI data types. For details turn to the ANSI standard documentation. Usage of other data types is of course possible, but you should be aware that this makes your application dependent on the database you are using at the moment.
When inputting data using sql_query/[2,3] the values will always be in string format as they are part of an SQL-query. Example:
odbc:sql_query(Ref, "INSERT INTO TEST VALUES(1, 2, 3)").
Note that when the value of the data to input is a string, it
has to be quoted with
\011odbc:sql_query(Ref, "INSERT INTO EMPLOYEE VALUES(1, 'Jane', 'Doe', 'F')").
You may also input data using
To find out which data types will be returned for the
columns in a table use the function
Grouping of SQL queries can be desirable in order to reduce network traffic. Another benefit can be that the data source sometimes can optimize execution of a batch of SQL queries.
Explicit batches an procedures described below will result in multiple results being returned from sql_query/[2,3]. while with parameterized queries only one result will be returned from param_query/[2,3].
The most basic form of a batch is created by semicolons separated SQL queries, for example:
"SELECT * FROM FOO; SELECT * FROM BAR" or
"INSERT INTO FOO VALUES(1,'bar'); SELECT * FROM FOO"
Different databases may also support creating of procedures that contains more than one SQL query. For example, the following SQLServer-specific statement creates a procedure that returns a result set containing information about employees that work at the department and and a result set listing the customers of that department.
CREATE PROCEDURE DepartmentInfo (@DepartmentID INT) AS
\011SELECT * FROM Employee WHERE department = @DepartmentID
\011SELECT * FROM Customers WHERE department = @DepartmentID
To effectively perform a batch of similar queries, you can use
parameterized queries. This means that you in your SQL query
string will mark the places that usually would contain values
with question marks and then provide lists of values for each
parameter. For instance you can use this to insert multiple
rows into the