[gdal-dev] Re-loading non-spatial data using OGR2OGR

[J. Burnson]

Hi,
 
Later tests suggest that ogr2ogr is checking ALL_SDO_GEOM_METADATA for this table, even though the table is non-spatial (and declared as such). The lack of a record there is a trigger for ogr to create the table de novo.
 
I am able to trick the program by manually registering a (fictitious) shape column for the table in SDO_GEOM_METADATA. Thereafter, ogr2ogr has no trouble loading and re-loading. Not ideal but progress of a sort!
 
John

--- On Thu, 1/26/12, Chaitanya kumar CH <chaitanya.ch at gmail.com> wrote:


From: Chaitanya kumar CH <chaitanya.ch at gmail.com>
Subject: Re: [gdal-dev] Re-loading non-spatial data using OGR2OGR
To: "J. Burnson" <jburnson at yahoo.com>
Cc: gdal-dev at lists.osgeo.org
Date: Thursday, January 26, 2012, 12:10 PM


John,
Try setting the layer creation option MULTI_LOAD to NO using -lco with ogr2ogr and the configuration option CPL_DEBUG  to OFF [1]. I hope to get at least a more usable error message.

[1]: http://trac.osgeo.org/gdal/wiki/ConfigOptions


On Thu, Jan 26, 2012 at 10:31 PM, J. Burnson <jburnson at yahoo.com> wrote:











Hi,
I am trying to load a non-spatial CSV file into Oracle using ogr2ogr (GDAL 1.8.1). It works on the first attempt (when no destination table exists) but in later attempts, I get "name is already used by an existing object".
 
ogr2ogr -append -f OCI OCI:user/password at db -nln r_sign_ogr X:/R_Sign.csv -nlt NONE
 
I have tried every combination of overwrite/append/update that I can think of, as well as using "-nlt NONE". I do not have trouble re-populating spatial tables.
 
Any suggestions would be welcome! Thank you,
John
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



-- 
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20120126/8b50c7ca/attachment.html