The answer, of course, is "It depends."

Tim Bunce's definition is very precise: DBI is no more and no less that he states. It will shield you from platform dependences in the host program, if you use it as intended. Also, if you use platform-specific (driver-specific) features, at least you can find those quickly when you're trying to port the system.

Of course, it can't guarantee someone won't write non-portable SQL. If you stick to a well-known standard like SQL-92, then there's a very good chance you'll be able to move your DBI-based program across different RDBMS with a minimum of fuss. However, that will also limit your ability to take advantage of platform-specific optimizations. Is the non-portability worth the gain? "It depends" on your shop, what you're doing, and so on.

As for the support question, this is probably one of the best places to get help during development, and even to troubleshoot production code. Depending on your platform, you may be able to purchase support contracts from the likes of ActiveState. (I'm presuming you mean DBI support, not RDBMS support, which is a whole 'nuther thing.) In spite of the fact that there's no single entity standing behind Perl, the support network is in fact huge. You're much more likely to get a reasonable answer here than from a vendor's tech support phone line.

DBI is very solid and heavily used in many business applications. There is support for tons of different databases, including Oracle.

The advantage of using DBI is that since the DBI interface is identical for each database that it supports, you are free to migrate your data from one database to another without having to modify your perl code that accesses it. All you need to do is update the code to use a different driver.

Yeah, sometimes you have to make changes to your code because of new database limitations, but migration issues are very seldom related to the DBI.

It is entirely possible, though unlikely, for Oracle to change OCI completely from one release to the next, thus totally breaking DBD::Oracle. Therefore, it's a good idea to run an Oracle version that is known to work, if possible. When you upgrade Oracle, you should QA your application to verify that it hasn't been broken by some new OCI madness.

The real question is wether DBD::Oracle supports it.

From DBD::Oracle:

<QUOTE>"DBD::Oracle is a Perl module which works with the DBI module to provide access to Oracle databases (both version 7 and 8)"</QUOTE>

So, you might have issues if version 9 is not backwards compatable with version 8. That is, until somebody gets around to updating DBD::Oracle to be forward compatable.

I've had no problems using DBD::Oracle (actually the DBD::Oracle8 PPD from Activestate) against a 9i database using 8i client libraries on a W2K box.

rdfield

as far as DBI is concerned, I'm pretty sure you will be ok, since DBI is a wrapper... if something gets broken, it would be DBD::Oracle. Or some non-portable SQL you may have (but since you are switching from oracle to oracle, I guess the latter shouldn't be an issue). Also, I've heard that Oracle is one of the better supported platforms in the set of DBD's, so if something breaks with oracle 9, it would be fixed quickly... another thing: oracle9 has been stable for quite a while now, so I guess they have all the bugs fixed (if they were any) in DBD::Oracle, but you should take a quick look at the changelog for the latest version of DBD::Oracle to be on the safe side.

hope this helps,

• Nature of the data being stored, that is does it contain data that for some reason product X (in our case DBI) does not handle well and requires a lot of massaging to work.
• What type of company are you in? Are you in the type that keeps detailed records of what is installed where and would know who to contact BEFORE it makes an upgrade or at a company that makes an upgrade and wonders why it can't access anything.
• Company policy. Does your company have a policy or commitment to its share holders or powers that be that it use only X type products? This may seem like it is an obvious thing, but I have been burned by it before. Make sure the solution you are suggesting is allowed on the network in the first place.
• Support Services. Who provides support for product X? Are they aware of it being implemented?
• Future needs. Is this company going to be able to manage product X in the future with its current mind set or is this something being brought in the back door in the dark of the night? Make sure the comany can and is willing to support product X, especailly if it is a critical app.
• Ability to justify. This is for when everyone has looked high and low for a solution that solves the problem, but some of the above items are missing. You need to present to them how product X can save them both time and money and illustrate how it can be applied to other areas.