#809: v.db.addtable consistently fails in winGrass ------------------------------+--------------------------------------------- Reporter: JonBall | Owner: [email protected] Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Vector | Version: svn-releasebranch64 Resolution: | Keywords: v.db.addtable, wingrass Platform: MSWindows Vista | Cpu: x86-64 ------------------------------+--------------------------------------------- Comment (by hamish):
> Replying to [comment:11 hamish]: > > stuff to audit, both for spaces in path names and for correct > > column parsing when fs=':' and a path like "C:\Documents and > > Settings" is being parsed. Replying to [comment:12 mmetz]: > I had a look at the vector lib routines for reading/writing > database connections (dblinks in the vector libs). > > The database is written to dbln without parsing any variables in > it; that makes it possible to copy entire locations or provide > sample datasets with vectors and attribute tables. Any variables > in the database info are parsed by Vect_get_dblink() which calls > Vect_subst_var(). However, there is no reason to assume that the user has not manually connected the vector to a real pathname. And in those cases any code which reads the dbln file will need to be able to deal with databases with spaces in the path name. suggestion: This is really a failure of the dbln file format. In grass 7 change the dbln file format to use '|' as the field sep. Include code in both the g7 and g6.5 the library functions to quietly read either during the transition period. We have done something similar for the color table format which used to be "value red green blue" but is now "value red:green:blue". > v.db.addtable calls v.db.connect which calls Vect_get_dblink() -> > any variables like $GISDBASE/$LOCATION_NAME/$MAPSET are already > substituted. > > The only way I see to get the database used by an existing layer > *without* parsing any variables is raw parsing of the dbln file. I came to the same conclusion and checked in that exact fix to svn a couple of hours ago. > AFAICT, vector modules use default database connection settings > when adding a new table, also when e.g. adding a table for layer > 2 and there is already a table connected to layer 1. Therefore it > would not be unusual behaviour if v.db.addtable also always uses > the default database connections. For now I have followed the path of least change and left it using what the map is already using. One thing I see in favor of having it use the mapset's VAR setting instead is that you can control the VAR setting. You can't control what the map already has in it unless you rebuild the map (which is perhaps not what you want). Another plausible possibility is to add database= and driver= options to v.db.addtable. Hamish -- Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:13> GRASS GIS <http://grass.osgeo.org>
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
