[GRASS5] [bug #3367] (grass) SQL error when renaming a vector layer

Morten Hulden morten at untamo.net
Sat Jun 25 05:46:19 EDT 2005


Maciek Sieczka wrote:
> From: "Morten Hulden" <morten at untamo.net>
> 
>> Request Tracker wrote:
>>
>>> GRASS 6.1.cvs (caves_utm33):~ > g.rename vect=utm_km,4_utm_km
>>> RENAME [utm_km] to [4_utm_km]
>>> DBMI-DBF driver error:
>>> SQL parser error in statement:
>>> create table 4_utm_km ( cat integer, row integer, col integer )
>>> Cannot create table
>>>
>>> WARNING: Cannot create new table
>>> WARNING: Cannot copy table
>>> WARNING: Cannot rename utm_km to 4_utm_km
>>>
>>> Is it by design? I couldn't find any information that vector layer names
>>> cannot start with a digit.
>>
>>
>> A dbf/psql restriction and should not be reported as a Grass bug
> 
> 
> OK. Anyway - why is g.rename trying to rename to "4_utm_km" and actually
> *does it* if such name is not supported due to dbf driver limitations? No
> logic. There should be an appropriate check and blocking for such actions
> folowed by an information about the restriction involved - like in some v.*
> modules (say v.mkgrid).
> 
> Are there more modules which do not verify the resulting vector layer 
> name according to dbf/psql restrictions?

I guess that's because part of the information associated with the 
vector is stored in Grass data directories where normal file system name 
restrictions apply, while categories and attributes, and (for PostGIS) 
even geometry, are stored in database tables where db-restrictions apply.

When you create a vector with a name starting with a digit the file 
system does not complain, but db-engine does. Same thing for renaming, 
except that the category table does not even exist because it was not 
created in the first place.

This perhaps should be handled more gracefully, by setting restictions 
early according to highest common factor, e.g. having Grass preventing 
vector names starting with a digit or containing special chars, max 10 
character field names (dbf), no upper chars or mixed case (allowed but a 
nuisance in Postgres), no reserved words etc

Developers working with this on a daily basis will probably give you a 
better explanation ...

Morten




More information about the grass-dev mailing list