Am 09.05.2012 23:32, schrieb Markus Neteler:
On Wed, May 9, 2012 at 5:29 PM, Falko Engel<falko.engel@web.de> wrote:
Dear list,
I had a strange behavior of v.buffer today:
v.buffer input=mydata output=mydata_buf bufcolumn=my_buf_col
results in an error:
"DBMI-Postgres driver error:
Cannot select:
SELECT cat, my_buf_col FROM mydata"
However, if I copy the exact statement of the error message into
echo "SELECT cat, my_buf_col FROM mydata" | db.select
the result is fine!
You could set this:
g.gisenv set=DEBUG=3
then relaunch the command to see if the more detailed output contains
relevant pieces (to post here, not all please :-).
To disable debug output, use
g.gisenv set=DEBUG=0
Markus
...
I'm using the following setup:
Opensuse 11.3, GRASS GIS 6.4.2
My attribute tables are stored in a Postgres DB which is located on a
network server.
All other DB operations in GRASS are fine.
Falko
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Dear Markus,
thanks for that hint! It helped finding the error.
I have to explain in a little more detail:
As I said my attribute tables are stored in a Postgres DB. I used to run the DB on localhost. But some weeks ago I moved it to a network drive for backup and accessibility reasons. Since I basically copied the old DB to the network drive the old DB still exists on localhost. So does the data set I used in the v.buffer example. Same DB name, same table name.
When I use db.select on this dataset I get the DB connection:
D3/3: db_driver_open_database() driver=pg database definition = 'host=my_server,dbname=my_db'
D3/3: parse_conn : host=my_server,dbname=my_db
D3/3: token 0 : host=my_server
D3/3: token 1 : dbname=my_db
D3/3: host = my_server, port = (null), options = (null), tty = (null), dbname = my_db, user = (null), password = (null), schema = (null)
When I use v.buffer:
D3/3: db_driver_open_database() driver=pg database definition = 'my_db'
D3/3: parse_conn : my_db
D3/3: host = (null), port = (null), options = (null), tty = (null), dbname = my_db, user = (null), password = (null), schema = (null)
So far the problem is clear. v.buffer seems connect to the old DB on localhost.
But there is another aspect:
When I create a new dataset (using g.copy) with an a attribute table in the (correct) DB on the network drive v.buffer recognizes it! This new table doesn't exists on localhost.
Is there a way to pipe the debugging info to a file?
Falko