[Gdal-dev] Re: [GRASS5] v.in.ogr behaviour
Stephan Holl
holl at gdf-hannover.de
Wed Mar 15 03:37:26 EST 2006
Hello Lists,
[crosspost again]
On Mon, 13 Mar 2006 12:09:15 +0100 Stephan Holl <holl at gdf-hannover.de>
wrote:
> Dear list,
>
> [sorry for crossposting, but perhaps this is interesting for the
> GDAL-folks as well]
>
> I am working with GRASS6_CVS and Oracle 9i which is compiled into
> GDAL/OGR 1.3.1. Everything works if the tables in Oracle are owned by
> the given user.
> v.in.ogr reports the available layers as follows:
> v.in.ogr -l dsn="OCI:owneroftables/pw at OCI" layer=DATA1 out=data1
> Data source contains 2 layers:
> DATA1, DATA2
>
> Removing the -l-switch imports the data nicly and creates dataset
> data1 inside GRASS.
>
> When I create another oracle-user with only
> SELECT-privileges on that table, the tables inside Oracle are shown
> like this:
>
> v.in.ogr -l dsn="OCI:readonlyuser/pw at OCI" layer=OWNEROFTABLES.DATA1
> out=data1
> Data source contains 2 layers:
> OWNEROFTABLES.DATA1, OWNEROFTABLES.DATA2
>
> Trying to import now, this results in a Segmentation fault.
> v.in.ogr dsn="OCI:readonlyuser/pw at OCI" layer=OWNEROFTABLES.DATA1
> out=data1
>
> So I assume the dot between user and table produces this?! Perhaps
> anybody can give me a hint where to look at.
>
> Using ogr2ogr works with both users and exports e.g. a shapefile
> correct.
>
> Thanks in advance for any pointers.
Apparently noone has stumbled over this I will provide as much
information for the developers.
I have created a full gdb backtrace[1] of the segfault. But again, I do
not know where to dig into the problem since I do know what is going on
there...
Thank you for having a look what might go wrong here.
Best regards
Stephan
[1] http://www.gdf-hannover.de/holl/tmp/v.in.ogr_bt-full.txt
--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl at gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508
More information about the Gdal-dev
mailing list