[GRASS-dev] [GRASS GIS] #1796: wingrass7: some db.*-modules fails with dbf as db-backend

GRASS GIS trac at osgeo.org
Fri Dec 7 03:18:30 PST 2012


#1796: wingrass7: some db.*-modules fails with dbf as db-backend
----------------------+-----------------------------------------------------
 Reporter:  hellik    |       Owner:  grass-dev@…              
     Type:  defect    |      Status:  new                      
 Priority:  critical  |   Milestone:  7.0.0                    
Component:  Database  |     Version:  svn-trunk                
 Keywords:  dbf       |    Platform:  MSWindows 7              
      Cpu:  x86-64    |  
----------------------+-----------------------------------------------------

Comment(by mmetz):

 Replying to [comment:8 martinl]:
 > Replying to [comment:7 hellik]:
 >
 > > some references to the computer used for location setup?
 >
 > this is probably related to `v.db.reconnect.all -c` which has been used
 when converting data from DBF to SQLite. I will fix the module later in
 the evening.

 The bug (newly introduced in r53609) is that the variables $GISDBASE,
 $LOCATION_NAME, $MAPSET have been substituted in the name of the new
 database. Looking at the dbln file of a vector, it reads e.g.

 {{{
 1/boundary_county|boundary_county|cat|$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db|sqlite
 }}}

 and not
 {{{
 1/boundary_county|boundary_county|cat|\home\neteler\grassdata\nc_spm_lat
 est\nc_spm_08\PERMANENT/sqlite/sqlite.db|sqlite
 }}}

 Database modules and vector modules usually take care of variable
 substitution themselves where appropriate, e.g. `v.db.connect`, which is
 called by `v.db.reconnect.all`.

 Should be easy to fix.

 Markus M

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1796#comment:9>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list