db.in.ogr fails with .dbf files created with Visual Foxpro

[maitl]

Import of .dbf table created with Visual Foxpro ends with "ERROR: Input DSN <C:\mytable.dbf> not found or not readable" . The problem is probably related to the .dbf file header where file structure is described (​https://msdn.microsoft.com/en-us/library/aa975386(v=vs.71).aspx).

When I converted the problematic table in Visual Foxpro environment to Foxpro 2.x format (command COPY TO mytable_fox26x TYPE FOX2X), then dbf.in.ogr works.

If fixing the issue is complicated, then I suggest to add a note to manual that "dBASE tables created with Visual Foxpro are not supported" and a recommendation how to proceede.

[maitl]

Two tables for testing

[martinl]

Since DBF driver is obsolete in GRASS 7 and will be probably removed in GRASS 8 I think that reported issue will not fixed. Could you suggest changes in manual? Ideally as attached patch. Thanks.

[mlennert]

Replying to maitl:

Import of .dbf table created with Visual Foxpro ends with "ERROR: Input DSN <C:\mytable.dbf> not found or not readable" . The problem is probably related to the .dbf file header where file structure is described (​https://msdn.microsoft.com/en-us/library/aa975386(v=vs.71).aspx).

When I converted the problematic table in Visual Foxpro environment to Foxpro 2.x format (command COPY TO mytable_fox26x TYPE FOX2X), then dbf.in.ogr works.

I cannot reproduce with GRASS 7.2.1 and GDAL 2.2.1:

> db.in.ogr table_VFP_import_fail.dbf out=test
Imported table <test> with 5 rows
> db.in.ogr table_FOX2x_import_ok.dbf out=test2
Imported table <test2> with 5 rows
> db.select table=test
X|Y|PE|ME_MREG|M1HB|M1KU|M1KS|M1LV|M1LM|M1MA|M1TL|M2|JRK|MID|xNullFlags
373094|6464908|13|47|0|0|0|0|0|47|0|0|150818|483611848311|
374195|6462403|11|230|23|12|115|0|0|80|0|0|150818|1345853648111|
374489|6464662|13|184|0|0|4|0|0|180|0|0|270634|907614648111|
375069|6463314|13|182|0|0|0|0|0|182|0|0|150818|483611048311|
375288|6472475|13|103|0|0|0|0|0|103|0|0|270634|1016537148111|
> db.select table=test2
X|Y|PE|ME_MREG|M1HB|M1KU|M1KS|M1LV|M1LM|M1MA|M1TL|M2|JRK|MID
373094|6464908|13|47|0|0|0|0|0|47|0|0|150818|483611848311
374195|6462403|11|230|23|12|115|0|0|80|0|0|150818|1345853648111
374489|6464662|13|184|0|0|4|0|0|180|0|0|270634|907614648111
375069|6463314|13|182|0|0|0|0|0|182|0|0|150818|483611048311
375288|6472475|13|103|0|0|0|0|0|103|0|0|270634|1016537148111

I also don't think that this would be an issue with the GRASS GIS dbf driver as db.in.ogr uses ogr to read the file. So if there is an issue it is probably with your version of GDAL.

What do

ogrinfo table_VFP_import_fail.dbf and ogrinfo table_VFP_import_fail.dbf table_VFP_import_fail

give you ?

What version of GDAL do you have installed.

[maitl]

Ok, I see that both tables can be imported on a different machine.

I found several ogrinfo binaries from my machine.

# "C:\Program Files\GDAL\ogrinfo"  --version
GDAL 1.11.1, released 2014/09/24

# "C:\Program Files\GRASS GIS 7.2.1\extrabin\ogrinfo" --version
GDAL 2.1.3, released 2017/20/01

#c:\osgeo4w\bin\ogrinfo --version
GDAL 1.11.2, released 2015/02/10

All can read the problematic table_VFP_import_fail.dbf and print the file content with -sql switch.

The output from all these ogrinfo exemplars is attached (ogrinfo_of_dbf_tables.zip​) . There are differences on field types as interpreted by different ogrinfo versions, but this is probably not important.

The output of ogrinfo from problematic table contains additional rows with

_NullFlags: String (2.0)
: String (0.0)
: String (0.0)
: String (0.0)
: String (0.0)
: String (0.0)
: String (0.0)
: String (0.0)
: String (0.0)