[GRASS-dev] Re: [GRASS GIS] #672: v.distance -a with upload=to_attr
and table= option: problems in table creation and value upload
GRASS GIS
trac at osgeo.org
Mon Oct 25 09:24:20 EDT 2010
#672: v.distance -a with upload=to_attr and table= option: problems in table
creation and value upload
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Vector | Version: unspecified
Keywords: v.distance | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by mlennert):
Replying to [comment:2 mlennert]:
> When using an SQLite backend, the trouble seems to come from the fact
that the same database and table are accessed twice. Maybe some playing
around with db_close_database_shutdown_driver might help, but I haven't
had the opportunity to play around with that. Anybody have any hints about
this ?
I can now confirm that this is a database locking issue. When doing
{{{
g.copy vect=myhosp,myhosp2
cp $GISDBASE/$MAPSET/sqlite.db ~/
v.db.connect -o myhosp2 driver=sqlite database=~/sqlite.db key=cat
table=myhosp2
v.distance from=myhosp to=myhosp2 upload=cat,dist,to_attr to_column=CANCER
column=to_cat,dist,to_cancer table=distance_cancer
}}}
it works, i.e distance_cancer contains values in the to_cancer column.
I would imagine that this kind of sqlite database locking will be a
problem in other modules as well, so this probably needs a wider solution
than just within this module. Anyone out there with enough experience with
SQLite to attack this ? This is very important if SQLite is to become the
default db backend...
Moritz
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/672#comment:3>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list