[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