in reply to DBD::ODBC vs. DBD::Oracle

DBD::Oracle uses Oracle's native API. DBD::ODBC uses ODBC to interface. In general if you can make DBD::Oracle work, I prefer to go that way. If you can't, DBD::ODBC works but won't give you full access to all of the features of Oracle.

Now about your Perl version. I don't know what 64-bit Perl you're using. In general I would recommend using a 32-bit Perl unless you really need to use many GB of RAM in one process. Furthermore I would suggest you get your Perl from http://strawberryperl.com/. There are known large problems with lots of standard modules in Activestate's version. Odds are better that you can get DBD::Oracle working with Strawberry Perl than with Activestate's version or by trying to start from scratch yourself.

Replies are listed 'Best First'.
Re^2: DBD::ODBC vs. DBD::Oracle
by Jenda (Abbot) on Aug 23, 2008 at 09:35 UTC
    "known large problems with lots of standard modules in Activestate's version"?

    I've been using ActiveState's (formerly ActiveWare, formerly Hip Communications) Perl since about '97 so I suppose if there were "known large problems" especially with "standard modules" I would be aware of them. May I ask what do you mean?

    Jenda
    Support Denmark!
    Defend the free world!

[reply]
      According to reports that I've seen the default ppm repository supplied by ActiveState does not build Scalar::Util or List::MoreUtils. Which means that it does not include any CPAN module that uses either of them, or depends on something that does. Like Test::More. Which turns out to be about 2/3 of CPAN. And the remaining third isn't exactly the highest quality third.

      This was the motivation for Strawberry Perl in the first place. And to the best of my knowledge, the problem still exists despite promises to make it better Real Soon Now. But even if they do make it better, the design problem that caused this still exists in PPM, so we can expect it to eventually descend into something like the current mess again some day.

      For further information see ActivePerl PPM repository design flaw goes critical and ActiveState finally starting to lift it's game.

[reply]
Re^2: DBD::ODBC vs. DBD::Oracle
by chuckd (Scribe) on Aug 23, 2008 at 05:19 UTC
    thanks for the advice. I thought it would be nice to use a 64 bit version of Perl because our server is a 64 bit machine. In some cases we are using lots of memory for a single process (creating huge hashes, huge arrays, lists, etc) and we are using a 64 bit version of Oracle. So, if I decide to go with StrawberryPerl, which only supports a 32bit version) will it be easy to install DBD::Oracle?
[reply]

      If you are on a 64-bit platform, you'll be far better off--performance, memory, support--using a 64-bit build of perl, than restricting yourself to a 32-bit build on the basis of a piece of idealogically motivated FUD from someone who takes pride in declaring that he doesn't use your target platform.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      I can't promise it will be easy, but it is worth a try. With Strawberry Perl you would need to run the command 
      perl -MCPAN -e shell

      [download]
      which will start the CPAN shell. After answering a series of questions you'll need to type in: 
      install DBI
install DBD::Oracle

      [download]
      and there is a good chance that it will work. If it doesn't, well, you can install Strawberry Perl in some private location first while you run the experiment. If it fails, just delete the directory. If it succeeds, you can play with it for a while before deciding that that is the direction you want to go.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom