[gdal-dev] Retreivinng a table with a condition using ogr2ogr OCI

[Even Rouault]

Le mardi 21 avril 2015 16:43:44, Jukka Rahkonen a écrit :
> Even Rouault <even.rouault <at> spatialys.com> writes:
> > Ammar,
> > 
> > it seems that the resulting layer from the SQL query is called "SELECT *
> > FROM TABLE WHERE ....", which is a bit an unfortunate choice (other
> > drivers generally call it "result" or "sql_statement", etc...
> > Anyway, add "-nln the_layer_name_you_like" to avoid this.
> > Alternatively you can add  -where "DETAILTYPE = 'Something'" in your
> > first ogr2ogr command that operates on the table, as opposed to a full
> > SQL request.
> 
> If I read the command right:
> "ogr2ogr 3011 -f "ESRI Shapefile" OCI:"user/password <at> ... "
> 
> it does not follow the ogr2ogr syntax as documented in
> http://www.gdal.org/ogr2ogr.html
> 
> ogr2ogr .... dst_datasource_name src_datasource_name

Jukka,

The target filename (directory) is 3011 in the above. Although it is 
recommanded to put options starting with a dash character before other 
options, the parser is pretty tolerant about that.
From the statements that work and the ones that do not work, and what I saw in 
the OCI driver code, I do think the issue comes from the implicit naming of a 
OCI SQL resulting layer.

Even

> 
> The command is lacking the dst_datasource name. The real bug for my mind is
> that ogr2ogr still tries to create an output. It should rather throw an
> error "No destination defined".
> 
> Try with
> "ogr2ogr 3011 -f "ESRI Shapefile" output.shp OCI:"user/password <at>... "
> 
> 
> -Jukka Rahkonen-
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com