Re: About prepared statements asnd transactions....

Ed wrote:
>> DBD::Mysql and DBD::Pg (for older versions of PostgreSQL only) emulate the
>> capability of having multiple active sth's per dbh by reading all the data
>> from an unfinished sth into memory when a second sth is executed. I
>> suggested adding similar emulation of this capability to DBD::Sybase to
>> Michael in February 2004, but nothing came of it, AFAIK.

Michael replied:
> It's feasible, but it is potentially problematic if the original
> $sth has a lot of pending data. I guess it could be an option.

Agreed, but transparently opening a second connection to the database and
violating transactional integrity seems even more problematic to me.

Making it an explicit option could be useful in some cases, but I think the
ideal default behavior should be a mixture of the two based on the state of
AutoCommit: If AutoCommit is off for a given dbh, then the unread results of
an unfinished sth should be read and cached in memory when a second sth is
executed. Transactional integrity is thus retained at the expense of memory
resources. If AutoCommit is on, then the current behavior of transparently
opening a database connection is acceptable and probably preferred. I suppose
that, if for some reason another database connection cannot be made (e.g.,
server maxed out on client connections), it could fallback on caching the
results of the unfinished sth and re-using the same connection, even when
AutoCommit is on.

OK, that got way too complicated there at the end. :-/ It would probably be
more straightforward and better to just always cache the results of
unfinished sth's by default.