Date: Wed, 20 Jan 1999 21:02:32 +0100
From: Michael Meskes <Michael_Meskes@usa.net>
To: Bruce Tenison <btenison@rstc.cc.al.us>
Cc: PostgreSQL Interfaces <pgsql-interfaces@postgresql.org>
Subject: Re: [INTERFACES] ECPG Question
Message-ID: <19990120210232.A293@gmx.net>
Mail-Followup-To: Bruce Tenison <btenison@rstc.cc.al.us>,
	PostgreSQL Interfaces <pgsql-interfaces@postgresql.org>
References: <000c01be449b$57fa6580$0105a8c0@tenison.irstc.cc.al.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <000c01be449b$57fa6580$0105a8c0@tenison.irstc.cc.al.us>;
	from Bruce Tenison on Wed, Jan 20, 1999 at 11:35:59AM -0600

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.Meskes@gmx.net          | Use PostgreSQL!