this bug's URL: http://intevation.de/rt/webrt?serial_num=3367
-------------------------------------------------------------------------
Subject: SQL error when renaming a vector layer
Platform: GNU/Linux/i386
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: cvs 21.06.2005
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.
Maciek
-------------------------------------------- Managed by Request Tracker
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
From: "Morten Hulden" <morten@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?
Maciek
Maciek Sieczka wrote:
From: "Morten Hulden" <morten@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