Re: I have problems with installing DBI-1.48 on Freebsd 5.4

Nick wrote: Hello dbi-users, Hi. I have problems with installing DBI-1.48 on Freebsd 5.4 here attached output. I have v5.8.6 built for i386-freebsd-64int Please help me to solve this problem === Checking if your kit

Re: it works, but...

Dear Gerardo, Perl + DBI + DBD::Informix imposes at least a moderate amount of overhead compared with a raw ESQL/C program. Whether the time ratio you are seeing is reasonable is slightly more debatable, but I would expect the Perl combination to be slower. The big question for you is is it

Re: DBI v2 - The Plan and How You Can Help [DRAFT]

Hi, Is something like connection pooling considered outside the scope of DBI? If not that would be a big one for me. Apache::DBI only goes so far. I guess 2. would be a sensible requirement for this as well. Thanks, Eric At 10:21 AM 7/3/2005, Dean Arnold wrote: Dean Arnold wrote:

Re: DBI v2 - The Plan and How You Can Help

On Mon, 04 Jul 2005 15:04:43 -0700, Dean Arnold wrote: Hi Dean Also, I'm not sold on the idea that a ~/.dbi file is particularly secure in that regard. Not neccesarily opposed, just not convinced its the right solution. (I don't like cleartext passwords either, but due to the variance in

Re: DBI v2 - The Plan and How You Can Help

- support for automatically pulling database DSN information from a ~/.dbi (or similar) file. This is constantly re-invented poorly. Let's just do a connect by logical application name and let the SysAdmins sort out which DB that connects to, in a standard way. This reminds me

Re: DBI v2 - The Plan and How You Can Help

Richard Nuttall wrote: - support for automatically pulling database DSN information from a ~/.dbi (or similar) file. This is constantly re-invented poorly. Let's just do a connect by logical application name and let the SysAdmins sort out which DB that connects to, in a standard

Re: DBI v2 - The Plan and How You Can Help

Richard Nuttall wrote: - support for automatically pulling database DSN information from a ~/.dbi (or similar) file. This is constantly re-invented poorly. Let's just do a connect by logical application name and let the SysAdmins sort out which DB that connects to, in a standard

Re: DBI v2 - The Plan and How You Can Help

Tim et al, Following are some ideas I have for the new DBI, that were thought about greatly as I was both working on Rosetta/SQL::Routine and writing Perl 6 under Pugs. These are all language-independent and should be implemented at the Parrot-DBI level for all Parrot-hosted languages to

Re: DBI v2 - The Plan and How You Can Help

Darren Duncan wrote: 3. Redefine prepare() and execute() such that the first is expressly for activities that can be done apart from a database (and hence can also be done for a connection handle that is closed at the time) while all activities that require database interaction are deferred to

Re: DBI v2 - The Plan and How You Can Help

Okay, considering that using the same name prepare() like this may confuse some people, here is a refined solution that uses 3 methods instead; please disregard any contrary statements that I previously made: # Opt 1: A user that wants the most control can do this (new feature): my $sth1