[GRASS-user] Unexplained DBI-DBMF error from v.in.ogr

GRASS GRASS user
, ,
1

I am running v.in.ogr to import a PostGIS table. This table shows up fine in QGIS. Here’s the command:
v.in.ogr -o “dsn=PG:dbname=‘de’ host=localhost port=5432 user=‘[redacted]’ password=‘[redacted]’ sslmode=disable” layer=consistent.master output=master_grassX

This command was produced by QGIS’s GRASS Tools.

The problem is that I get an error but no explanation at all. Here’s the output:

Width for column school_zone set to 255 (was not specified by OGR), some strings may be truncated!

Width for column vehicle_color set to 255 (was not specified by OGR), some strings may be truncated!

Width for column offense_location set to 255 (was not specified by OGR), some strings may be truncated!

Width for column work_zone set to 255 (was not specified by OGR), some strings may be truncated!

DBMI-DBF driver error:

Unable to create table: ‘create table master_grassX (cat integer, offense_street_name varchar ( 30 ), school_zone varchar ( 255 ), defendant_dl varchar ( 20 ), defendant_dl_state varchar ( 2 ), vehicle_model varchar ( 20 ), offense_code integer, vehicle_color varchar ( 255 ), citation_id_base varchar ( 20 ), vehicle_make varchar ( 20 ), defendant_dob date, speed_limit integer, source varchar ( 20 ), vehicle_registration_expiration_date date, offense_crossstreet_number varchar ( 10 ), defendant_sex varchar ( 1 ), citing_jurisdiction integer, offense_county varchar ( 10 ), officer_id varchar ( 20 ), offense_location varchar ( 255 ), defendant_zip varchar ( 9 ), vehicle_licenseplate_state varchar ( 2 ), offense_street_number varchar ( 10 ), offense_timestamp datetime, citation_id_stub varchar ( 20 ), offense_crossstreet_name varchar ( 30 ), speed_alleged integer, vehicle_year integer, vehicle_licenseplate varchar ( 10 ), work_zone varchar ( 255 ), defendant_race varchar ( 10 ))’

Finished with error

The problem is I get no details at all on the error cause. Yes, the driver error really is blank.

I turned postgres logging to log all queries (following the recipe at http://stackoverflow.com/questions/722221/how-to-log-postgres-sql-queries). I analyzed the queries and didn’t see anything surprising. I’ve attached the log in case it’s helpful.

I checked the /dbf directory, and it has no files. I also checked the vector/master_grassX directory and found no problems, just four files (coor, dbln, head, hist) with unsurprising contents.

I’m new to GRASS, so I’m not sure what else to check. Is there another log source? Did I discover a bug that needs to be filed?

Aren Cambre

(attachments)

postgres.log (6.76 KB)

2

I think the problem may actually be with the build of GRASS GIS shipped with QGIS. I just installed 6.4.1 RC1 and now get a useful error.

Aren

On Sat, Feb 5, 2011 at 10:15 PM, Aren Cambre <aren@arencambre.com> wrote:

I am running v.in.ogr to import a PostGIS table. This table shows up fine in QGIS. Here’s the command:
v.in.ogr -o “dsn=PG:dbname=‘de’ host=localhost port=5432 user=‘[redacted]’ password=‘[redacted]’ sslmode=disable” layer=consistent.master output=master_grassX

This command was produced by QGIS’s GRASS Tools.

The problem is that I get an error but no explanation at all. Here’s the output:

Width for column school_zone set to 255 (was not specified by OGR), some strings may be truncated!

Width for column vehicle_color set to 255 (was not specified by OGR), some strings may be truncated!

Width for column offense_location set to 255 (was not specified by OGR), some strings may be truncated!

Width for column work_zone set to 255 (was not specified by OGR), some strings may be truncated!

DBMI-DBF driver error:

Unable to create table: ‘create table master_grassX (cat integer, offense_street_name varchar ( 30 ), school_zone varchar ( 255 ), defendant_dl varchar ( 20 ), defendant_dl_state varchar ( 2 ), vehicle_model varchar ( 20 ), offense_code integer, vehicle_color varchar ( 255 ), citation_id_base varchar ( 20 ), vehicle_make varchar ( 20 ), defendant_dob date, speed_limit integer, source varchar ( 20 ), vehicle_registration_expiration_date date, offense_crossstreet_number varchar ( 10 ), defendant_sex varchar ( 1 ), citing_jurisdiction integer, offense_county varchar ( 10 ), officer_id varchar ( 20 ), offense_location varchar ( 255 ), defendant_zip varchar ( 9 ), vehicle_licenseplate_state varchar ( 2 ), offense_street_number varchar ( 10 ), offense_timestamp datetime, citation_id_stub varchar ( 20 ), offense_crossstreet_name varchar ( 30 ), speed_alleged integer, vehicle_year integer, vehicle_licenseplate varchar ( 10 ), work_zone varchar ( 255 ), defendant_race varchar ( 10 ))’

Finished with error

The problem is I get no details at all on the error cause. Yes, the driver error really is blank.

I turned postgres logging to log all queries (following the recipe at http://stackoverflow.com/questions/722221/how-to-log-postgres-sql-queries). I analyzed the queries and didn’t see anything surprising. I’ve attached the log in case it’s helpful.

I checked the /dbf directory, and it has no files. I also checked the vector/master_grassX directory and found no problems, just four files (coor, dbln, head, hist) with unsurprising contents.

I’m new to GRASS, so I’m not sure what else to check. Is there another log source? Did I discover a bug that needs to be filed?

Aren Cambre

3

I think the problem may actually be with the build of GRASS GIS shipped with QGIS. I just installed 6.4.1 RC1 and now get a useful error.

Could be that you came across a bug, but…
If you’re trying to import a PostGIS table into GRASS as a GRASS vector, then you need to note what database GRASS is using. From the error below your GRASS db connection (‘db.connect -p’) is local dbf files. In that case I believe that several of the column headers from the original PostGIS table are too long for the dbf format. That might be part of the problem… Also it could be that some of the data types from PostGIS aren’t accepted by dbf.
It might be best to move your whole GRASS database setup to sqlite - more robust and full featured.

··· 
-- 
Micha Silver
[http://www.surfaces.co.il/](http://www.surfaces.co.il/)
Arava Development Co.  +972-52-3665918
4

Thank you. This is a clean install of GRASS 6.4.0.

I hear you on the column warnings, but does that explain a missing password error? Seems like two different errors. I did some Googling earlier and what I found suggests the column warnings aren’t a big deal.

Aren

On Mon, Feb 7, 2011 at 4:54 AM, Micha Silver <micha@arava.co.il> wrote:

On 06/02/2011 07:35, Aren Cambre wrote:

I think the problem may actually be with the build of GRASS GIS shipped with QGIS. I just installed 6.4.1 RC1 and now get a useful error.

Could be that you came across a bug, but…
If you’re trying to import a PostGIS table into GRASS as a GRASS vector, then you need to note what database GRASS is using. From the error below your GRASS db connection (‘db.connect -p’) is local dbf files. In that case I believe that several of the column headers from the original PostGIS table are too long for the dbf format. That might be part of the problem… Also it could be that some of the data types from PostGIS aren’t accepted by dbf.
It might be best to move your whole GRASS database setup to sqlite - more robust and full featured.

Aren

On Sat, Feb 5, 2011 at 10:15 PM, Aren Cambre <aren@arencambre.com> wrote:

I am running v.in.ogr to import a PostGIS table. This table shows up fine in QGIS. Here’s the command:
v.in.ogr -o “dsn=PG:dbname=‘de’ host=localhost port=5432 user=‘[redacted]’ password=‘[redacted]’ sslmode=disable” layer=consistent.master output=master_grassX

This command was produced by QGIS’s GRASS Tools.

The problem is that I get an error but no explanation at all. Here’s the output:

Width for column school_zone set to 255 (was not specified by OGR), some strings may be truncated!

Width for column vehicle_color set to 255 (was not specified by OGR), some strings may be truncated!

Width for column offense_location set to 255 (was not specified by OGR), some strings may be truncated!

Width for column work_zone set to 255 (was not specified by OGR), some strings may be truncated!

DBMI-DBF driver error:

Unable to create table: ‘create table master_grassX (cat integer, offense_street_name varchar ( 30 ), school_zone varchar ( 255 ), defendant_dl varchar ( 20 ), defendant_dl_state varchar ( 2 ), vehicle_model varchar ( 20 ), offense_code integer, vehicle_color varchar ( 255 ), citation_id_base varchar ( 20 ), vehicle_make varchar ( 20 ), defendant_dob date, speed_limit integer, source varchar ( 20 ), vehicle_registration_expiration_date date, offense_crossstreet_number varchar ( 10 ), defendant_sex varchar ( 1 ), citing_jurisdiction integer, offense_county varchar ( 10 ), officer_id varchar ( 20 ), offense_location varchar ( 255 ), defendant_zip varchar ( 9 ), vehicle_licenseplate_state varchar ( 2 ), offense_street_number varchar ( 10 ), offense_timestamp datetime, citation_id_stub varchar ( 20 ), offense_crossstreet_name varchar ( 30 ), speed_alleged integer, vehicle_year integer, vehicle_licenseplate varchar ( 10 ), work_zone varchar ( 255 ), defendant_race varchar ( 10 ))’

Finished with error

The problem is I get no details at all on the error cause. Yes, the driver error really is blank.

I turned postgres logging to log all queries (following the recipe at http://stackoverflow.com/questions/722221/how-to-log-postgres-sql-queries). I analyzed the queries and didn’t see anything surprising. I’ve attached the log in case it’s helpful.

I checked the /dbf directory, and it has no files. I also checked the vector/master_grassX directory and found no problems, just four files (coor, dbln, head, hist) with unsurprising contents.

I’m new to GRASS, so I’m not sure what else to check. Is there another log source? Did I discover a bug that needs to be filed?

Aren Cambre

This mail was received via Mail-SeCure System.


_______________________________________________
grass-user mailing list
[grass-user@lists.osgeo.org](mailto:grass-user@lists.osgeo.org)
[http://lists.osgeo.org/mailman/listinfo/grass-user](http://lists.osgeo.org/mailman/listinfo/grass-user)

This mail was received via Mail-SeCure System.


-- 
Micha Silver
[http://www.surfaces.co.il/](http://www.surfaces.co.il/)
Arava Development Co.  +972-52-3665918
5

Thank you. This is a clean install of GRASS 6.4.0.

So you can set the local GRASS database to sqlite with the db.connect command.
I think you first need to create an empty sqlite database with:

first get the environment variables:

eval g.gisenv

create a database file

sqlite $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db

Enter .q to leave the sqlite command line

Now change the default database settings

db.connect driver=sqlite database=$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db

(If you’re on Windows, do the equivalent with the gui, or with the correct env variable delimiter ‘%’ and path separator ''.

Now try to import the Postgresql table.

I hear you on the column warnings, but does that explain a missing password error? Seems like two different errors. I did some Googling earlier and what I found suggests the column warnings aren’t a big deal.

I don’t see any password error?

··· 
-- 
Micha Silver
[http://www.surfaces.co.il/](http://www.surfaces.co.il/)
Arava Development Co.  +972-52-3665918
6

Oops, sorry! Disregard what I wrote. This was from running the GRASS GIS 6.4.0 that is packaged with QGIS 1.6.0. It appears this version of GRASS is suppressing error messages. I’ve filed a bug report at http://trac.osgeo.org/qgis/ticket/3470 (GRASS error(s?) missing error details).

If you could, check the email that I sent about 15 hours ago titled “fe_sendauth: no password” even though password supplied. It’s a more up-to-date version of this.

Thanks,

Aren

On Mon, Feb 7, 2011 at 8:17 AM, Micha Silver <micha@arava.co.il> wrote:

On 07/02/2011 16:03, Aren Cambre wrote:

Thank you. This is a clean install of GRASS 6.4.0.

So you can set the local GRASS database to sqlite with the db.connect command.
I think you first need to create an empty sqlite database with:

first get the environment variables:

eval g.gisenv

create a database file

sqlite $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db

Enter .q to leave the sqlite command line

Now change the default database settings

db.connect driver=sqlite database=$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db

(If you’re on Windows, do the equivalent with the gui, or with the correct env variable delimiter ‘%’ and path separator ''.

Now try to import the Postgresql table.

I hear you on the column warnings, but does that explain a missing password error? Seems like two different errors. I did some Googling earlier and what I found suggests the column warnings aren’t a big deal.

I don’t see any password error?

–
Micha

Aren

On Mon, Feb 7, 2011 at 4:54 AM, Micha Silver <micha@arava.co.il> wrote:

On 06/02/2011 07:35, Aren Cambre wrote:

I think the problem may actually be with the build of GRASS GIS shipped with QGIS. I just installed 6.4.1 RC1 and now get a useful error.

Could be that you came across a bug, but…
If you’re trying to import a PostGIS table into GRASS as a GRASS vector, then you need to note what database GRASS is using. From the error below your GRASS db connection (‘db.connect -p’) is local dbf files. In that case I believe that several of the column headers from the original PostGIS table are too long for the dbf format. That might be part of the problem… Also it could be that some of the data types from PostGIS aren’t accepted by dbf.
It might be best to move your whole GRASS database setup to sqlite - more robust and full featured.

Aren

On Sat, Feb 5, 2011 at 10:15 PM, Aren Cambre <aren@arencambre.com> wrote:

I am running v.in.ogr to import a PostGIS table. This table shows up fine in QGIS. Here’s the command:
v.in.ogr -o “dsn=PG:dbname=‘de’ host=localhost port=5432 user=‘[redacted]’ password=‘[redacted]’ sslmode=disable” layer=consistent.master output=master_grassX

This command was produced by QGIS’s GRASS Tools.

The problem is that I get an error but no explanation at all. Here’s the output:

Width for column school_zone set to 255 (was not specified by OGR), some strings may be truncated!

Width for column vehicle_color set to 255 (was not specified by OGR), some strings may be truncated!

Width for column offense_location set to 255 (was not specified by OGR), some strings may be truncated!

Width for column work_zone set to 255 (was not specified by OGR), some strings may be truncated!

DBMI-DBF driver error:

Unable to create table: ‘create table master_grassX (cat integer, offense_street_name varchar ( 30 ), school_zone varchar ( 255 ), defendant_dl varchar ( 20 ), defendant_dl_state varchar ( 2 ), vehicle_model varchar ( 20 ), offense_code integer, vehicle_color varchar ( 255 ), citation_id_base varchar ( 20 ), vehicle_make varchar ( 20 ), defendant_dob date, speed_limit integer, source varchar ( 20 ), vehicle_registration_expiration_date date, offense_crossstreet_number varchar ( 10 ), defendant_sex varchar ( 1 ), citing_jurisdiction integer, offense_county varchar ( 10 ), officer_id varchar ( 20 ), offense_location varchar ( 255 ), defendant_zip varchar ( 9 ), vehicle_licenseplate_state varchar ( 2 ), offense_street_number varchar ( 10 ), offense_timestamp datetime, citation_id_stub varchar ( 20 ), offense_crossstreet_name varchar ( 30 ), speed_alleged integer, vehicle_year integer, vehicle_licenseplate varchar ( 10 ), work_zone varchar ( 255 ), defendant_race varchar ( 10 ))’

Finished with error

The problem is I get no details at all on the error cause. Yes, the driver error really is blank.

I turned postgres logging to log all queries (following the recipe at http://stackoverflow.com/questions/722221/how-to-log-postgres-sql-queries). I analyzed the queries and didn’t see anything surprising. I’ve attached the log in case it’s helpful.

I checked the /dbf directory, and it has no files. I also checked the vector/master_grassX directory and found no problems, just four files (coor, dbln, head, hist) with unsurprising contents.

I’m new to GRASS, so I’m not sure what else to check. Is there another log source? Did I discover a bug that needs to be filed?

Aren Cambre

This mail was received via Mail-SeCure System.


_______________________________________________
grass-user mailing list
[grass-user@lists.osgeo.org](mailto:grass-user@lists.osgeo.org)
[http://lists.osgeo.org/mailman/listinfo/grass-user](http://lists.osgeo.org/mailman/listinfo/grass-user)

This mail was received via Mail-SeCure System.


-- 
Micha Silver
[http://www.surfaces.co.il/](http://www.surfaces.co.il/)
Arava Development Co.  +972-52-3665918

This mail was received via Mail-SeCure System.

-- 
Micha Silver
[http://www.surfaces.co.il/](http://www.surfaces.co.il/)
Arava Development Co.  +972-52-3665918