[GRASS-dev] Re: [GRASS GIS] #809: v.db.addtable consistently fails in winGrass

[GRASS GIS]

#809: v.db.addtable consistently fails in winGrass
------------------------------+---------------------------------------------
  Reporter:  JonBall          |       Owner:  grass-dev at lists.osgeo.org
      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 mmetz):

 Replying to [comment:13 hamish]:
 > 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.

 Right, and it should also be broken on Linux if there are whitespaces in
 the path name when manually connecting a table. A mystery that no one
 discovered that yet...
 >
 > 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".

 OK. And use G_tokenize() I assume.
 >
 > 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.

 Makes sense, and should not make the code too complicated. Something for
 g7?

 Markus M

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:15>
GRASS GIS <http://grass.osgeo.org>