Thread: ECPG could not connect to the database.
Hello, I´m trying to use embedded sql with postgresql through ecpg. But if I try to make a connection to my database, I get the following error at runtime: Could not connect to database buecher@localhost in line 18. (I´m using postgresql 7.0.2) psql and the jdbc is working, but not the ecpg connection. I tried the follwing connect statements: exec sql connect to buecher; exec sql connect to buecher user joe; exec sql connect to buecher user joe identified by blubber; and everything ends in the same message. Do I have to configure something additionally for ecpg? Or anything else special? Hope you could help me? Thanks in advance. Joachim.
On Mon, Dec 04, 2000 at 10:11:00AM +0100, Joachim Jaeckel wrote: > I´m trying to use embedded sql with postgresql through ecpg. But if I > try to make a connection to my database, I get the following error at > runtime: > > Could not connect to database buecher@localhost in line 18. > (I´m using postgresql 7.0.2) Do you write a log file? Does it contain anything additional information? > psql and the jdbc is working, but not the ecpg connection. Are you sure you use the very same connect string? psql and libecpg both use libpq to connect to the database. Maybe you have some different settings in some environment variables? Or do you use IP numbers? I know that libecpg does not connect to a given IP number while psql does. Frankly I have no ide whatsoever where this comes from. But I have to figure out before we relaese. > exec sql connect to buecher; > exec sql connect to buecher user joe; > exec sql connect to buecher user joe identified by blubber; > > and everything ends in the same message. How does your psql connect command look like? > Do I have to configure something additionally for ecpg? Or anything else > special? No. It should work without any special configuration. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
On Mon, Dec 04, 2000 at 10:11:00AM +0100, Joachim Jaeckel wrote:
> Hello,
>
> I´m trying to use embedded sql with postgresql through ecpg. But if I
> try to make a connection to my database, I get the following error at
> runtime:
>
> Could not connect to database buecher@localhost in line 18.
> (I´m using postgresql 7.0.2)
>
> psql and the jdbc is working, but not the ecpg connection.
>
> I tried the follwing connect statements:
>
> exec sql connect to buecher;
> exec sql connect to buecher user joe;
> exec sql connect to buecher user joe identified by blubber;
>
> and everything ends in the same message.
>
> Do I have to configure something additionally for ecpg? Or anything else
> special?
>
> Hope you could help me?
I'm sorry that I am answering that question after a month, but i
did not see someone solving your problem.
First of all - you have done everything right with your code. You
simply rediscovered a long standing ECPG BUG, which was introduced years
ago in PostgreSQL 6.4 (or was it 6.3?). This bug was reported here by me
and other people, we had found where is the problem and how to work around
this ;) (Hi developers... I hope that you are reading this... Maybe it's
about the time to fix it...? :))).
So, here is the work-around and explanation of the bug:
ECPG is generating wrong code. Try to generate *.c file by ecpg,
and look at the generated "ECPGconnect". In my case that line looks like this:
--8<--
{ ECPGconnect(__LINE__, NULL, "biblioteka" , NULL ,NULL, 0);}
--8<--
But that is wrong, it should look like this:
--8<--
{ ECPGconnect(__LINE__, "biblioteka" , NULL , NULL ,NULL, 0);}
--8<--
So, the workaround is to change the second argument of ECPGconnect
for the third argument, inside code generated by ecpg.
If you do not want to do it every time you will change your source
code and have to recompile it, write:
ECPGconnect(__LINE__, "buecher" , NULL , NULL ,NULL, 0);
instead of
exec sql connect to buecher;
inside your source code.
Best regards,
--- Artur Pietruk, arturp@plukwa.net
--- IBM RS6000/AIX System Administrator, SQL/C++ programmer
On Wed, Jan 03, 2001 at 01:20:43AM +0100, Artur Pietruk wrote:
> > try to make a connection to my database, I get the following error at
> > runtime:
> ...
> I'm sorry that I am answering that question after a month, but i
> did not see someone solving your problem.
I did. But I had private conversation with Joachim instead of using the
list.
> First of all - you have done everything right with your code. You
Apparently this was not the case.
> simply rediscovered a long standing ECPG BUG, which was introduced years
Interesting. I do not know about this special bug. I have to admit there are
some outstanding bugs that I won't be able to fix before 7.1 comes out, but
this one is new to me.
Anyone willing to spend some time digging the hostname problem? That is why
ecpg programs need to specify a hostname and not an IP number to connect,
while psql for instance works with both?
> ago in PostgreSQL 6.4 (or was it 6.3?). This bug was reported here by me
> and other people, we had found where is the problem and how to work around
> this ;) (Hi developers... I hope that you are reading this... Maybe it's
> about the time to fix it...? :))).
Would be interesting to know the version number of ecpg you are talking
about.
> ECPG is generating wrong code. Try to generate *.c file by ecpg,
> and look at the generated "ECPGconnect". In my case that line looks like this:
I just ran test1.pgc from the source tree through ecpg 2.8.0 and then
grepped for ECPGconnect:
...
{ ECPGconnect(__LINE__, "mm" , NULL,NULL , "main", 0);
strcpy(msg, "connect");
{ ECPGconnect(__LINE__, "pm" , NULL,NULL , NULL, 0);
...
Just for curiosity I also tried ecpg 2.7.1 which comes with 7.0.3:
...
{ ECPGconnect(__LINE__, "mm" , NULL,NULL , "main", 0);
strcpy(msg, "connect");
{ ECPGconnect(__LINE__, "pm" , NULL,NULL , NULL, 0);
...
> { ECPGconnect(__LINE__, NULL, "biblioteka" , NULL ,NULL, 0);}
So this of course brings me to wonder which version you are using.
> But that is wrong, it should look like this:
>
> --8<--
> { ECPGconnect(__LINE__, "biblioteka" , NULL , NULL ,NULL, 0);}
> --8<--
As it does.
Michael
--
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> Anyone willing to spend some time digging the hostname problem? That is why
> ecpg programs need to specify a hostname and not an IP number to connect,
> while psql for instance works with both?
I do not see how that can be ecpg's fault --- it just does
this->connection = PQsetdbLogin(NULL, NULL, NULL, NULL, dbname, user, passwd);
which means that any specification of the host must come from the PGHOST
environment variable and will be handled entirely inside libpq.
If ecpg behaves differently from psql (for the same PGHOST setting)
I would imagine that this means different versions of libpq are being
used in the two cases. It might be worth checking shared library
search paths and so forth to try to identify the difference.
Within recent versions of libpq, the given PGHOST string is simply
passed to gethostbyname(). On the machines I've used, gethostbyname()
will accept numeric IP addresses as well as domain names ... but I
suppose there might be C libraries out there that are pickier. What
is the platform showing this problem?
regards, tom lane
On Sun, Jan 07, 2001 at 02:52:07PM -0500, Tom Lane wrote: > I do not see how that can be ecpg's fault --- it just does > > this->connection = PQsetdbLogin(NULL, NULL, NULL, NULL, dbname, user, passwd); > > which means that any specification of the host must come from the PGHOST > environment variable and will be handled entirely inside libpq. Not exactly. It is possible to use PGHOST but you also can add the hostname to the dbname. > suppose there might be C libraries out there that are pickier. What > is the platform showing this problem? I'm not sure. I was mailed this by a user but don't know which platform he uses. However, I can reproduce the problem on my Linux machine. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> On Sun, Jan 07, 2001 at 02:52:07PM -0500, Tom Lane wrote:
>> I do not see how that can be ecpg's fault --- it just does
>>
>> this->connection = PQsetdbLogin(NULL, NULL, NULL, NULL, dbname, user, passwd);
>>
>> which means that any specification of the host must come from the PGHOST
>> environment variable and will be handled entirely inside libpq.
> Not exactly. It is possible to use PGHOST but you also can add the hostname
> to the dbname.
Have you tried it lately? I suspect that you are depending on code that
is not in libpq's current sources anymore. I fully agree with Peter E's
reasons for removing it, too. We do not need to overload the definition
of libpq's dbname parameter.
regards, tom lane
Tom Lane writes: > > Not exactly. It is possible to use PGHOST but you also can add the hostname > > to the dbname. > > Have you tried it lately? I suspect that you are depending on code that > is not in libpq's current sources anymore. I fully agree with Peter E's > reasons for removing it, too. We do not need to overload the definition > of libpq's dbname parameter. Ouch, it *is* documented in ecpg(1). I guess if ecpg wants to provide this syntax (which it probably should, since the "sql connect to" syntax doesn't have any other provisions for host name, port, etc.) then it could take the code from libpq (it's still in there I think) and do the parsing before calling PQsetdbLogin(). -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
>> Have you tried it lately? I suspect that you are depending on code that
>> is not in libpq's current sources anymore. I fully agree with Peter E's
>> reasons for removing it, too. We do not need to overload the definition
>> of libpq's dbname parameter.
> Ouch, it *is* documented in ecpg(1). I guess if ecpg wants to provide
> this syntax (which it probably should, since the "sql connect to" syntax
> doesn't have any other provisions for host name, port, etc.) then it could
> take the code from libpq (it's still in there I think) and do the parsing
> before calling PQsetdbLogin().
That would make sense to me. It would be a good idea to fix the bugs
you were complaining of in November. The thing that jumped out at me
in a quick look is that update_db_info is freeing the initial
conn->dbName before it is done scanning it.
regards, tom lane
On Mon, Jan 08, 2001 at 06:20:42PM +0100, Peter Eisentraut wrote: > > is not in libpq's current sources anymore. I fully agree with Peter E's > > reasons for removing it, too. We do not need to overload the definition > > of libpq's dbname parameter. Why? Sorry, it seems I missed his mail. > Ouch, it *is* documented in ecpg(1). I guess if ecpg wants to provide > this syntax (which it probably should, since the "sql connect to" syntax > doesn't have any other provisions for host name, port, etc.) then it could > take the code from libpq (it's still in there I think) and do the parsing > before calling PQsetdbLogin(). This is a possibility of course. But why should this syntax be taken away from other apps using libpq? Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Where did we end on this? > Peter Eisentraut <peter_e@gmx.net> writes: > >> Have you tried it lately? I suspect that you are depending on code that > >> is not in libpq's current sources anymore. I fully agree with Peter E's > >> reasons for removing it, too. We do not need to overload the definition > >> of libpq's dbname parameter. > > > Ouch, it *is* documented in ecpg(1). I guess if ecpg wants to provide > > this syntax (which it probably should, since the "sql connect to" syntax > > doesn't have any other provisions for host name, port, etc.) then it could > > take the code from libpq (it's still in there I think) and do the parsing > > before calling PQsetdbLogin(). > > That would make sense to me. It would be a good idea to fix the bugs > you were complaining of in November. The thing that jumped out at me > in a quick look is that update_db_info is freeing the initial > conn->dbName before it is done scanning it. > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Michael Meskes <meskes@postgresql.org> writes:
> On Mon, Jan 08, 2001 at 06:20:42PM +0100, Peter Eisentraut wrote:
>>>> is not in libpq's current sources anymore. I fully agree with Peter E's
>>>> reasons for removing it, too. We do not need to overload the definition
>>>> of libpq's dbname parameter.
> Why? Sorry, it seems I missed his mail.
Check pghackers from late November or so. But in brief --- the code is
broken, it's not documented (at least not in the libpq documentation),
it interferes with accessing databases whose names contain funny
characters, and it looks likely to create compatibility problems with
future standards. It also didn't play well with the Unix-socket-path-
specification change, IIRC.
>> Ouch, it *is* documented in ecpg(1). I guess if ecpg wants to provide
>> this syntax (which it probably should, since the "sql connect to" syntax
>> doesn't have any other provisions for host name, port, etc.) then it could
>> take the code from libpq (it's still in there I think) and do the parsing
>> before calling PQsetdbLogin().
> This is a possibility of course. But why should this syntax be taken away
> from other apps using libpq?
It's not being "taken away" from other apps, because there are no other
apps using it, because it's not documented as a feature of anything
except ecpg.
regards, tom lane
On Tue, Jan 09, 2001 at 12:11:58PM -0500, Tom Lane wrote: > broken, it's not documented (at least not in the libpq documentation), > it interferes with accessing databases whose names contain funny > characters, and it looks likely to create compatibility problems with > future standards. It also didn't play well with the Unix-socket-path- > specification change, IIRC. How do these standards look like? Back when I implemented this kind of database name specification we discussed it here and decided to go for this syntax. > It's not being "taken away" from other apps, because there are no other > apps using it, because it's not documented as a feature of anything > except ecpg. Yes, that's true. But IMO it would be a major plus if all apps can use the same database name. It's not that I desperately want this syntax. I'm willing to change ECPG to use the same syntax everything else uses. But how do you specify the database name to psql? Personally I do not think using environment variables is a good idea. For compatibility it should remain that way, but I would not recommend using this. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!