Skip to Content.
Sympa Menu

freetds - [freetds] managing two DBD::Sybase modules

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'freetds AT lists.ibiblio.org'" <freetds AT lists.ibiblio.org>
  • Subject: [freetds] managing two DBD::Sybase modules
  • Date: Mon, 6 Jan 2003 12:15:25 -0500

> From: Andrew Stanley [mailto:astanley AT cs.uml.edu]
> Sent: January 6, 2003 11:34 AM
>
> (I hacked DBD::Sybase to look like DBD::FreeTDS, so I could have
> 2 different DBD::Sybase's co-existing)

[musing]

Several people have mentioned the need to use FreeTDS and Sybase's libraries
at the same time in Perl. At present, that's only possible by using
DBD::Sybase for Sybase and DBD::ODBC or sybperl for FreeTDS. In limited
cases, it may be possible to get away with manipulating @INC to manage two
DBD::Sybase modules, but almost no one wants the administration headaches
that are sure to follow.

I wonder if there isn't/couldn't be a better way. For example, could the
namespace and module name of DBD::Sybase be altered at configuration time?
Could we use Perl namespaces another way, to convert DBD::Sybase into, say,
DBD::FreeTDS::Sybase?

Seems to me this could also be useful to test upgrades and patches.

Andrew used hackery. Is no mechanism available to make that unnecessary?

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.






Archive powered by MHonArc 2.6.24.

Top of Page