On Thu, Feb 14, 2013 at 11:26 PM, Hamish <[email protected]> wrote: > Hamish wrote: >> > I thought the question was still up in the air for g7 and >> > for now it was user choosable by the way you constructed the >> > db.connect string. > > Michael: >> How can you change the default by >> changing the db.connect string? I'd like to do it. >> >> I don't think it is all that difficult connecting tables >> across different vector objects, but agree (and said at the >> time) that it is probably a pretty rare occurrence in >> reality. > > hmm, I thought it did emulate the dbf way if you only speficied > the directory, but just testing it looks like it doesn't: > > [trunk] > cd $MAPSET > mkdir sqlite > db.connect driver=sqlite database='$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/' > echo "1|2|abc" | v.in.ascii in=- out=testmap > ... > DBMI-SQLite driver error: > Unable to open database: unable to open database file > > > we definitely should make that option work for people who > want/need that though. :) > > Is there a reason to collect them in a common $MAPSET/dbf/ > or $MAPSET/sqlite/ dir instead of under $MAPSET/vector/$MAPNAME/sqlite.db ? > (and would you want separate sqlite db files for > each db layer, or for a single map keep all of the layer > connections using the sqlite driver all in the same sqlite file?)
I guess the reason for one common sqlite database is the ability to do joins. In GRASS 6.4.1- it was possible to have a separate sqlite db for each vector in $MAPSET/vector/$MAP/sqlite.db. I have no idea why this option has been disabled. The VAR file can be DB_DRIVER: sqlite DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/vector/$MAP/sqlite.db Should we revert the changes that make it now impossible to have a separate sqlite db for each vector? Markus M > > Note v.pack(.py) demos the method to make a $MAPSET/vector/ > $MAPNAME/db.sqlite per-map extract. > > > Hamish > _______________________________________________ > grass-user mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-user _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
