[gdal-dev] Issue with ogrinfo: unixODBC and MS SQL

Frank Warmerdam warmerdam at pobox.com
Thu Mar 25 00:12:59 EDT 2010

Gregor at HostGIS wrote:
> Hey, this is so excellent. I took Frank's advice about just trying to 
> hack the C++ code... and discovered as a side effect that FreeTDS has a 
> new release. This new release fixed the issue. Ha!
> I do have one outstanding issue, though: it is very, very, very, very 
> slow because it scans every table instead of the 1 table/layer I 
> requested. More on this in a separate email, after I've given some 
> things a try...


You can specify a list of tables of interest in the ODBC connection
string.  This will dramatically reduce startup cost for complex
databases.  From the docs:

ODBC datasources are accessed using a datasource name of the form
With optional items dropped the following are also acceptable:

<li> <b>ODBC:<i>userid</i>/<i>password</i>@<i>dsn</i></b>
<li> <b>ODBC:<i>userid</i>@<i>dsn</i>,<i>table_list</i></b>
<li> <b>ODBC:<i>dsn</i>,<i>table_list</i></b>
<li> <b>ODBC:<i>dsn</i></b>
<li> <b>ODBC:<i>dsn</i>,<i>table_list</i>:<i>srs_tablename</i></b>
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 seperated 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 timeconsuming, so the ability to restrict the set of
tables accessed is primarily a performance issue.<p>

Best regards,
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

More information about the gdal-dev mailing list