[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:19 hamish]:
 > Replying to [comment:18 mmetz]:
 >
 > > One minor bug though: in the new v.db.addtable line 129 [g.findfile]
 > > does not work with a fully qualified name,
 >
 > interestingly it pretty much works if you just chop off the @mapset
 > part because g.findfile searches the full mapset path as a module would.
 The @mapset part is already chopped off previously, you can replace line
 129
 {{{
 eval `g.findfile elem="vector/$GIS_OPT_MAP" file=dbln`
 }}}
 with
 {{{
 eval `g.findfile elem="vector/$MAP_NAME" file=dbln mapset="$MAPSET"`
 }}}
 in order to get identical behaviour for fully qualified map names and map
 names without the @mapset part. Currently in relbr64 you get different
 results depending on whether you use a fully qualified name or not.
 >
 > Anyway, I've ripped this code out now in favor of using the VAR file's
 default DB settings for the mapset. So you are able to now control it
 instead of being locked to what the map was already using. Committed in
 6.5svn and trunk.

 That's probably the best solution.
 >
 > the only thing left to decide is when to backport this stuff to 6.4.
 You have already backported the Vect_read_dblinks() fix, I would opt to
 backport v.db.addtable as well.

 Markus M

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