Re: ODBC

Thanks to everyone that suggested -i, but looking in my postmaster.opts
file, it's already there.

There is an error number mentioned in the dialog box that
appears, -2147467259. It's when I'm trying to connect with pgAdmin.

I can connect to the database via telnet with "psql". I would try to connect
to the server with ODBC locally, but I don't know how.

---------------------------------------
 Stuart Grimshaw         |
 Schoolsnet LTD          |   Special
 www.schoolsnet.com      |   Projects
                         |   Developer
 stuart@smgsys.fsnet.co.uk
---------------------------------------

----- Original Message -----
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stuart Grimshaw <stuart@smgsys.fsnet.co.uk>
Cc: Postgres-General <pgsql-general@postgresql.org>
Sent: 29 May 2000 18:21
Subject: Re: [GENERAL] ODBC


> "Stuart Grimshaw" <stuart@smgsys.fsnet.co.uk> writes:
> > I'm having a problem connecting to my Postgres server with ODBC.
> > When I try and connect I get the error :
>
> > Could not connect to the server;
> > Could not connect to remote socket
>
> > I'm using Postgres v7.0, and I've allowed my local network
> > (10.0.0.0/255.0.0.0) access through pg_hba.conf with :
>
> > host    all    10.0.0.0    255.0.0.0    trust
>
> > the IP of the machine I'm connecting from is 10.0.0.2, so that's
covered.
>
> That pg_hba.conf entry looks OK, but I suspect that you are not getting
> as far as having the postmaster consult that file.  Looking at the code
> of our ODBC driver, I see that the error message "Could not connect to
> remote socket." is issued in only one place, namely if the connect()
> kernel call fails.  That means that you are unable to open a channel to
> the postmaster at all, let alone try to be authenticated as an allowed
> host/user.  I suspect network-level problems, or possibly specification
> of the wrong port number for the postmaster (though you say you checked
> that).
>
> Unfortunately the ODBC code neglects to notice exactly why the connect()
> call failed --- it'd be mighty useful here to know what errno code the
> kernel returned.  I'd suggest trying it with a libpq-based client,
> which will include the kernel error code in its error message in this
> situation, or else altering the ODBC code to print out errno when it
> gets this failure.  That'd give us something more to go on.
>
> regards, tom lane