Okay, I see your point, especially your comments on the object hierarchy.
Because here's the problem (someone must have seen this already):
PgCursor c("host=localhost", "foo");
c.Declare("select * from foo where something=somethingelse");
c.Fetch();
for (int i = 0; i < c.Tuples(); i++)
{ if (something is true) { c.ExecCommandOk("update bar set something=something where
something=somethingelse") ) }
}
c.Close();// just rolled back all those updates, but have no idea why!
Thanks
Dave
...
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "David Joyner" <d4ljoyn@yahoo.com>
Cc: <pgsql-interfaces@postgresql.org>
Sent: Monday, January 14, 2002 5:50 PM
Subject: Re: [INTERFACES] libpq++
> "David Joyner" <d4ljoyn@yahoo.com> writes:
> > I recently got the latest source from cvs. I think there's a bug in
> > pgtransdb.cc. The pgCommitted flag will never be true after the
implicit
> > BeginTransaction called by creating a PgCursor.
>
> This code is pretty grotty, but that particular issue I don't think is a
> problem. AFAICS, since a PgTransaction object opens its own database
> connection (yipes!), the only thing ever done in a PgCursor's
> transaction will be to create and read from the cursor. So whether we
> commit or abort hardly matters.
>
> The real bletcherousness is the overhead of establishing a separate
> connection for each transaction.
>
> Fixing this would probably entail a wholesale redesign of PgCursor,
> PgTransaction, and friends, and would break any applications that are
> using them successfully :-(
>
> There is someone working on a brand-new C++ interface library which
> perhaps will avoid all the mistakes that were made in libpq++. You
> might want to pitch in with that work. Check the recent archives
> for (I think) libpqxx.
>
> regards, tom lane
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com