EVOLUTION-MANAGER

Edit File: drv_odbc.html

<html>
<head>
<title>ODBC RDBMS</title>
</head>

<h1>ODBC RDBMS</h1>

OGR optionally supports spatial and non-spatial tables accessed via ODBC.
ODBC is a generic access layer for access to many database systems, and
data that can be represented as a database (collection of tables). ODBC
support is potentially available on Unix and Windows platforms, but is
only included in unix builds by special configuration options.

ODBC datasources are accessed using a datasource name of the form
ODBC:userid/password@dsn,schema.tablename(geometrycolname),...:srs_tablename(sridcolumn,srtextcolumn).
With optional items dropped the following are also acceptable:

<ul>
<li> ODBC:userid/password@dsn
<li> ODBC:userid@dsn,table_list
<li> ODBC:dsn,table_list
<li> ODBC:dsn
<li> ODBC:dsn,table_list:srs_tablename
</ul>

The dsn is the ODBC Data Source Name. Normally ODBC datasources
are setup using an ODBC Administration tool, and assigned a DSN. That DSN
is what is used to access the datasource.

By default the ODBC searches for GEOMETRY_COLUMNS table. If found it is
used to identify the set of spatial tables that should be treated as layers
by OGR. If not found, then all tables in the datasource are returned as
non-spatial layers. However, if a table list (a list of comma separated table
names) is provided, then only those tables will be represented as layers
(non-spatial). Fetching the full definition of all tables in a complicated
database can be quite time consuming, so the ability to restrict the set of
tables accessed is primarily a performance issue.

If the GEOMETRY_COLUMNS table is found, it is used to select a column to
be the geometry source. If the tables are passed in the datasource name,
then the geometry column associated with a table can be included in
round brackets after the tablename. It is currently a hardcoded assumption
that the geometry is in Well Known Binary (WKB) format if the field
is binary, or Well Known Text (WKT) otherwise. The GEOMETRY_COLUMNS
table should have at least the columns F_TABLE_NAME, F_GEOMETRY_COLUMN
and GEOMETRY_TYPE.

If the table has a geometry column, and has fields called XMIN, YMIN, XMAX
and YMAX then direct table queries with a spatial filter accelerate the
spatial query. The XMIN, YMIN, XMAX and YMAX fields should represent the
extent of the geometry in the row in the tables coordinate system.

By default, SQL statements are passed directly to the underlying database
engine. It's also possible to request the driver to handle SQL commands
with the <a href="ogr_sql.html">OGR SQL</a> engine, by passing
"OGRSQL" string to the ExecuteSQL() method, as name of
the SQL dialect.

<h2>Access Databases (.MDB) support</h2>

Starting with GDAL 1.10, and on Windows provided that the "Microsoft Access Driver (*.mdb)"
ODBC driver is installed, non-spatial MS Access Databases (not Personal
Geodabases or Geomedia databases) can be opened directly by their filenames.

<h2>Creation Issues</h2>

Currently the ODBC OGR driver is read-only, so new features, tables and
datasources cannot normally be created by OGR applications. This limitation
may be removed in the future. 
<h3>See Also</h3>

<ul>
<li> <a href="http://msdn.microsoft.com/en-us/library/ms714562(VS.85).aspx">MSDN ODBC API Reference</a>
<li> <a href="drv_pgeo.html">PGeo driver</a>
<li> <a href="drv_geomedia.html">Geomedia driver</a>
<li> <a href="drv_mdb.html">MDB driver</a>
</ul>

</body>
</html>