Skip site navigation (1) Skip section navigation (2)

Re: [INTERFACES] ECPG Question

From: Michael Meskes <Michael_Meskes(at)usa(dot)net>
To: Bruce Tenison <btenison(at)rstc(dot)cc(dot)al(dot)us>
Cc: PostgreSQL Interfaces <pgsql-interfaces(at)postgresql(dot)org>
Subject: Re: [INTERFACES] ECPG Question
Date: 1999-01-20 20:02:32
Message-ID: 19990120210232.A293@gmx.net (view raw or flat)
Thread:
Lists: pgsql-interfaces
On Wed, Jan 20, 1999 at 11:35:59AM -0600, Bruce Tenison wrote:
> Hi!  I hope that I'm in the correct list to ask this question.  We have a

Yes.

> daemon that need to access our PostgreSQL database and have been trying to
> use ecpg to generate the C source to use to access the database.  Basically,
> we're winding up with a bunch of open sockets for some reason.  Here's the
> function that accesses the database, and I'm wondering if we're closing the
> connection properly (since we call this routine quite often...)

The function listed below is not an embedded sql function as preprocessed by
ecpg. It only uses libecpg. Or is this the result of an ecpg run?

> int getuname(ipaddr)
> char *ipaddr;
> {
>         ECPGconnect("currentuser");

ECPGconnect is used to connect to a database. So you open a connection to DB
currentuser everytime you call this function.

> ...
>         ECPGtrans(__LINE__, "end");
> 
>         return not_found_uname;
> }

This only commits the transaction but does not disconnect from the database.
For that you need a call to ECPGfinish as done in ECPGdisconnect.

Michael
-- 
Michael Meskes                         | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz    | Go Rhein Fire!
Tel.: (+49) 2431/72651                 | Use Debian GNU/Linux!
Email: Michael(dot)Meskes(at)gmx(dot)net          | Use PostgreSQL!

In response to

Responses

pgsql-interfaces by date

Next:From: David GiffinDate: 1999-01-20 23:24:03
Subject: JDBC postgresql.Driver
Previous:From: Gregory W BurnhamDate: 1999-01-20 18:41:28
Subject: LockRelease error

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group