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

[Aren Cambre]

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 at 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 at 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 at 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 listgrass-user at lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/grass-user
>>
>> This mail was received via Mail-SeCure System.
>>
>>
>>
>>
>>
>> --
>> Micha Silverhttp://www.surfaces.co.il/
>> Arava Development Co.  +972-52-3665918
>>
>>
>
> This mail was received via Mail-SeCure System.
>
>
>
> --
> Micha Silverhttp://www.surfaces.co.il/
> Arava Development Co.  +972-52-3665918
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20110207/f50ef578/attachment-0001.html