Re: [gdal-dev] access attribute (non-spatial) data in .mdb with PGeo Driver

[Even Rouault]

Le lundi 14 novembre 2011 20:44:35, Eli Adam a écrit :
 Hi all,
 
 On Windows, I'm trying to access non-spatial tables in an .mdb file.
 With --debug on I see that the absence of a 'GDB_GeomColumns' table is
 the problem.
 
 ogrinfo --debug on Surveys.mdb
 
 PGeo: EstablishSession(DRIVER=Microsoft Access Driver
 (*.mdb);DBQ=Surveys.mdb) ODBC: SQLDriverConnect(DRIVER=Microsoft Access
 Driver (*.mdb);DBQ=Surveys.mdb) PGEO: SELECT on GDB_GeomColumns fails,
 perhaps not a personal geodatabase? [Microsoft][ODBC Microsoft Access
 Driver] The Microsoft Jet database engine cann ot find the input table or
 query 'GDB_GeomColumns'.  Make sure it exists and tha t its name is
 spelled correctly.
 ODBC: SQLDisconnect()
 
 I noticed this fairly recent commit, which seems to indicate that this
 is the desired behavior, http://trac.osgeo.org/gdal/changeset/21550

I'm confused because if you get to the point of having the trace  PGEO: 
SELECT on GDB_GeomColumns fails, perhaps not a personal geodatabase? it means 
that you got after the test of r21550 (which should have discared this mdb as 
having no GDB_GeomColumns table), so I highly suspect you are not using trunk 
version for this test.

r21550 only enforces what existed before : the PGeo driver can only handle 
PGeo MDBs. The new test was introduced specifically to avoid the PGeo driver to 
try opening a MDB that should be recognized by the Geomedia driver (new in 
trunk).

 
 I was able to access the non-spatial attributes by making a
 'GDB_GeomColumns' table and falsely populating it (and ignoring the
 missing 'GDB_SpatialRefs' table errors).
 
 TableName FieldName   ShapeType   ExtentLeft  ExtentBottom
 ExtentRight 
ExtentTop
   IdxOriginX  IdxOriginY  IdxGridSize SRIDHasZHasM
 SurveyShape   4   7255394.59721669241841.239197335
 7396378.9177745 
524650.46
 1230004   0   0   141508.9583397911   0   0
 
 ogrinfo -so Surveys.mdb Survey
 
 ERROR 1: 'SELECT srtext FROM GDB_SpatialRefs WHERE srid = 1' failed.
 [Microsoft][ODBC Microsoft Access Driver] The Microsoft Jet database engine
 cann ot find the input table or query 'GDB_SpatialRefs'.  Make sure it
 exists and tha t its name is spelled correctly.
 INFO: Open of `Surveys.mdb'
   using driver `PGeo' successful.
 
 Layer name: Survey
 Geometry: Unknown (any)
 Feature Count: 20790
 Extent: (7255394.597217, 241841.239197) - (7396378.917775, 524650.461230)
 Layer SRS WKT:
 (unknown)
 Geometry Column = Shape
 DocumentName: String (25.0)
 SurveyDate: DateTime (19.0)
 ...
 
 
 If the general case requires a 'GDB_GeomColumns' table, could no
 'GDB_GeomColumns' table be made a driver config option?

Why not using the generic ODBC driver for that use case ?

 
 I noticed that the new Access MDB driver,
 http://gdal.org/ogr/drv_mdb.html , does not require a GDB_GeomColumns
 table (tested on ubuntu 10.04 and gdal trunk).

Yes, it can understand PGeo MDBs, Geomedia MDBs and generic MDBs.

 
 
 Thanks, Eli
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] access attribute (non-spatial) data in .mdb with PGeo Driver

[Eli Adam]

Thanks Even.

 I'm confused because if you get to the point of having the trace  PGEO:
 SELECT on GDB_GeomColumns fails, perhaps not a personal geodatabase? it means
 that you got after the test of r21550 (which should have discared this mdb as
 having no GDB_GeomColumns table), so I highly suspect you are not using trunk
 version for this test.

Correct.  I'm using an old OSGeo4W 1.8dev.  Yes, I should have noticed
that I was not using the results of that r21550.


 r21550 only enforces what existed before : the PGeo driver can only handle
 PGeo MDBs. The new test was introduced specifically to avoid the PGeo driver 
 to
 try opening a MDB that should be recognized by the Geomedia driver (new in
 trunk).

I confirmed that I don't get that trace with the gisinternals
release-1600-gdal-mapserver (from about 2 weeks ago).  I also checked
with this before writing the list, but just checked that trunk also
didn't open the file.  I didn't redo the --debug on portion.


 Why not using the generic ODBC driver for that use case ?

This is apparently what I should have been doing.  I'll try that now.

Thanks, Eli
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev