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.

"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!

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.

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?

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

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.

The main advantage of using an ODBC connection is that it provides a layer of indirection between the application and the database to which it connects that can be remotely administered.

This is most useful in large organisations where the data the application uses may be split amongst various physical DB servers along political, departmental or physical location lines. The application can be deployed to workstations without change and which actual server it connects to can be control through the administration of the local ODBC connection. Often remotely.

It also provides for a level of isolation between the application and the type (vendor) of the DB holding its data. The caveat woth this usage is that the application must restrict itself to a common (non-proprietary) subset of the DBs SQL.

So, if you think the application might need to switch from using a local DB to a remote one; or from Oracle to DB2 or MySQL or Access at some point in its lifetime, then using ODBC up front might save you some hassles later. But as with any level of genericity, you must be aware of the restrictions it imposes, and unless you have a fairly strong belief you are going to need it, it is probably best avoided.

Just as a counterpoint to BrowserUK's comments--I use DBD::ODBC nearly exclusively.

My workload is basically: use the bulk loader to get the data into the database, and use vanilla SQL to operate on the data. For this usage, ODBC has been just fine for me. One thing I commonly hear is that "ODBC is slow". It might be, but I haven't seen any speed difficulties. Of course, I don't execute a bazillion tiny queries--I tend to tell the database to do large operations so that the communications overhead is pretty darned small. So I think I'd advise: "If you're already using ODBC for other databases, go ahead and use ODBC. If you find a speed or feature deficiency, you can always go to DBD::Oracle." In fact, that's what I decided long ago. I've just never been pushed onwards.

Having said that, you'll still need the oracle client software on your machine to use the ODBC interface, so installing DBD::ODBC probably won't save you any time or effort on the installation phase. So if you don't have DBD::ODBC on your machine, and you don't anticipate doing so, you might just try DBD::Oracle first.

It doesn’t matter much which one you use unless you have very specific requirements (like encryption for example). Nowadays ODBC is fast and reliable. In fact I would recommend it but this is probably my personal preference. I have worked a lot with the JDBC Thin driver (it’s Java brother) and have very good experiences with it. If you go ahead with ODBC make sure to put some effort in the selection process. Whether or not to choose a "wire protocol" ODBC driver or the more classical approach is worth consideration. Also the 32/64 bits choice plays a role. (Of course for bulk loading nothing beats SQL*Loader.)