Opened 5 years ago

Closed 3 years ago

#2385 closed defect (duplicate)

v.in.ogr doesn't use information from dblogin file about external PostgreSQL server

Reported by: hemeybo Owned by: martinl
Priority: normal Milestone: 7.2.0
Component: Database Version: svn-releasebranch70
Keywords: v.in.ogr PostgreSQL db.login db.databases Cc: grass-dev@…
CPU: x86-64 Platform: Linux

Description

To import data from an external PostgreSQL server with v.in.ogr, I want to use the dblogin file created with db.login with ip-address, user name and password for the login on the external server. Login on the server is working fine, since db.tables lists all tables on the server. Using db.databases with the location flag works also fine, listing all available databases on the external server. If I try to use v.in.ogr with the server login information in the dsn string (with password written in plain text!!), everything is doing ok. But since I don't want to write my password visible for everybody every time I use the import function, I think, it should be possible to use v.in.ogr with the login information of the dblogin file.

The error message, I recieve is the following:

"DBMI-PostgreSQL driver error: Unable to connect to Postgres: could not connect to server: No such file or directory

Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

DBMI-PostgreSQL driver error: Unable to connect to Postgres: could not connect to server: No such file or directory

Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

ERROR: Unable to list databases. Try to define correct connection settings

by db.login."

This occurs to be the same error message as if I use db.databases without the location flag.

For me, this somehow looks like the db.databases function is not working properly together with the dblogin file.

The same problem occurs with the use of v.external

Change History (11)

comment:1 Changed 5 years ago by martinl

This has been fixed in trunk, could you test it please? BTW, when using default DB connection, you can leave datasource string empty, see http://grass.osgeo.org/grass71/manuals/v.in.ogr.html#default-connection-settings-as-datasource-%28postgresql-only%29

comment:2 Changed 5 years ago by hemeybo

Unfortunately, there is not much improvement. The error moved on from "Unable to list databases" to "Unable to open data source" with the correct connection details. Here the new error message:

v.in.ogr dsn=PG: layer=bfn.nw_buk1000 output=nw_buk1001 ERROR 1: PQconnectdb failed. could not connect to server: No such file or directory

Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

ERROR: Unable to open data source

<PG:dbname=host=134.110.32.101,dbname=gis>

It seems like the dsn is not created properly - the first "dbname=" is wrong, in my opinion.

comment:3 in reply to:  2 Changed 5 years ago by martinl

Replying to hemeybo:

ERROR: Unable to open data source

<PG:dbname=host=134.110.32.101,dbname=gis>

It seems like the dsn is not created properly - the first "dbname=" is wrong, in my opinion.

please post here the commands in which you set up the connection settings (db.connect and db.login).

comment:4 Changed 5 years ago by hemeybo

here the commands for the connection settings:

db.connect driver=pg database="host=134.110.32.101,dbname=gis" db.login user=username pass=password

comment:5 Changed 4 years ago by martinl

I have implemented experimental support for db.login settings to v.in.ogr and v.external in r67510. There is unfortunately a duplicated code (dsn.c) which would be probably good to move to Vlib to avoid code duplication. We will need similar code for v.out.ogr, v.out.postgis and v.external.out. These modules already contain a duplicated code (list layers). It would make sense to move this duplicated code to the library (a new one, eg. libgrass_gdal) or to Vlib.

Similar situation for r.in.gdal, r.external and r.external.out. From this point of view a new library which would provide listing layers (both raster and vector), setting datasource would make more sense.

What do you think? Better ideas?

comment:6 Changed 4 years ago by martinl

Cc: grass-dev@… added
Milestone: 7.0.07.0.4
Owner: changed from grass-dev@… to martinl
Status: newassigned

comment:7 Changed 4 years ago by martinl

Milestone: 7.0.47.0.5

comment:8 Changed 3 years ago by martinl

Milestone: 7.0.57.2.0

This issue will be hardly solved in 7.0. Changing milestone to 7.2.

comment:9 Changed 3 years ago by mlennert

What is the status of this issue ? Should this be dealt with before moving into 7.2 hard freeze, or should we move the milestone to 7.4 ?

comment:10 Changed 3 years ago by mlennert

Is this a duplicate of #3167 ?

comment:11 in reply to:  10 Changed 3 years ago by martinl

Resolution: duplicate
Status: assignedclosed

Replying to mlennert:

Is this a duplicate of #3167 ?

Seems to be like that. Taking liberty to close the ticket. Feel free to reopen if needed.

Note: See TracTickets for help on using tickets.