Dear all,
I just came across an issue with vector maps in the PERMANENT mapset
and was wondering if anyone else had the same problem.
Whenever I want to get read access to a DBF attribute table for
a vector file in PERMANENT (while logged into a user mapset),
e.g. using "db.select <map>", I get:
DBMI-DBF driver error:
Table '<map>' doesn't exist.
Error in db_open_select_cursor()
I also get the "select cursor" error from other modules, such as
g.copy. Interestingly, I can log into the PERMANENT mapset and
then things work fine. I have checked the Unix file permissions
and they are OK. I have checked different GRASS location and
they consistently have the same problem.
I have not checked any DBMI other than DBF.
I tested this on a 6.4 SVN snapshot from May 9th 2009.
Cheers,
Ben
--
Benjamin Ducke
Senior Geospatial Consultant
Oxford Archaeology
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.
Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.ducke@oxfordarch.co.uk
------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.
On Wed, May 13, 2009 at 2:05 PM, Benjamin Ducke
<benjamin.ducke@oxfordarch.co.uk> wrote:
Dear all,
I just came across an issue with vector maps in the PERMANENT mapset
and was wondering if anyone else had the same problem.
Whenever I want to get read access to a DBF attribute table for
a vector file in PERMANENT (while logged into a user mapset),
... to my knowledge, you cannot with the db.* modules.
That's why the v.db.* modules exist, those work also cross-mapset.
I suggest to update the related document(s), e.g. [1].
Hope this (somewhat) helps,
Markus
[1] http://grass.osgeo.org/grass65/manuals/html65_user/databaseintro.html
OK, that clarifies it!
Thanks,
Ben
Markus Neteler wrote:
On Wed, May 13, 2009 at 2:05 PM, Benjamin Ducke
<benjamin.ducke@oxfordarch.co.uk> wrote:
Dear all,
I just came across an issue with vector maps in the PERMANENT mapset
and was wondering if anyone else had the same problem.
Whenever I want to get read access to a DBF attribute table for
a vector file in PERMANENT (while logged into a user mapset),
... to my knowledge, you cannot with the db.* modules.
That's why the v.db.* modules exist, those work also cross-mapset.
I suggest to update the related document(s), e.g. [1].
Hope this (somewhat) helps,
Markus
[1] http://grass.osgeo.org/grass65/manuals/html65_user/databaseintro.html
--
Benjamin Ducke
Senior Geospatial Consultant
Oxford Archaeology
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.
Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.ducke@oxfordarch.co.uk
------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.
On 13/05/09 14:28, Markus Neteler wrote:
On Wed, May 13, 2009 at 2:05 PM, Benjamin Ducke
<benjamin.ducke@oxfordarch.co.uk> wrote:
Dear all,
I just came across an issue with vector maps in the PERMANENT mapset
and was wondering if anyone else had the same problem.
Whenever I want to get read access to a DBF attribute table for
a vector file in PERMANENT (while logged into a user mapset),
... to my knowledge, you cannot with the db.* modules.
AFAIK, you can. The problem is that db.* modules use the mapset database definition by default, but if you explicitely set the databse= parameter to point to the dbf directory in PERMANENT, you should be able to access the data.
Moritz
On Thu, May 14, 2009 at 10:51 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 13/05/09 14:28, Markus Neteler wrote:
On Wed, May 13, 2009 at 2:05 PM, Benjamin Ducke
...
AFAIK, you can. The problem is that db.* modules use the mapset database
definition by default, but if you explicitely set the databse= parameter to
point to the dbf directory in PERMANENT, you should be able to access the
data.
ah ok - once this is verified please update/add a note in the
db/databaseintro.html
files.
thanks
Markus
Right, that works!
However, setting the mapset via the "database=" option is awkward, since
you need to know all the actual locations in the file/network system.
How about adding a "mapset=" option that resolves these more
transparently for the user?
Thanks,
Ben
Markus Neteler wrote:
On Thu, May 14, 2009 at 10:51 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 13/05/09 14:28, Markus Neteler wrote:
On Wed, May 13, 2009 at 2:05 PM, Benjamin Ducke
...
AFAIK, you can. The problem is that db.* modules use the mapset database
definition by default, but if you explicitely set the databse= parameter to
point to the dbf directory in PERMANENT, you should be able to access the
data.
ah ok - once this is verified please update/add a note in the
db/databaseintro.html
files.
thanks
Markus
--
Benjamin Ducke
Senior Geospatial Consultant
Oxford Archaeology
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.
Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.ducke@oxfordarch.co.uk
------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.
On 14/05/09 11:39, Benjamin Ducke wrote:
Right, that works!
However, setting the mapset via the "database=" option is awkward, since
you need to know all the actual locations in the file/network system.
Well, if you are in the same location, all you have to do is replace $MAPSET with PERMANENT.
How about adding a "mapset=" option that resolves these more
transparently for the user?
We could do that, but I think that the v.db.* modules already respond to that need. the db.* modules are meant as more generic database management modules which allow you to deal with any tables in any databases.
The major problem with using db.* in your context is that you have to know the name of the table. You suppose that it is equal to the name of the map, but this is not always the case...
Moritz