DBD :: ODBC vs win32 :: odbc
I wonder what advantages and disadvantages are used one over the other. This question arose from the advice I got here: Dynamically allocate a buffer for a DB query according to the actual record size
I'm looking for a list of important differences (not an exhaustive list) to help me make an informed decision. I have experience with win32 :: odbc and I can confirm this for real. It will be very helpful if someone can share their experiences on top of the dry documented details.
More information: The author of Win32 :: ODBC wrote here: http://www.roth.net/perl/odbc/docs/ODBC_Docs.htm - "There are several alternatives for Win32 :: ODBC, such as the DataBase Interface (DBI) called DBD :: ODBC. This ODBC Perl extension is available on different platforms such as Mac and UNIX. It is a good tool for ODBC database access, although it lacks some of the features that Win32 :: ODBC has. " I wonder if you know what features it lacks.
source to share
My main reasons for working in the stack DBI
are flexibility and a wider set of testers / debuggers. With help, DBI
you allow yourself to use a driver that is specifically configured for your particular database engine. Yes, most databases also offer an ODBC driver, but some specific capabilities may not be available or more complex through that particular API. In addition, it DBI
is platform independent, which makes possible future porting to another OS, which is much less of a problem. Finally, the population of people using DBI
to access the database far outnumbers the number of users using Win32::ODBC
, which means bugs are more likely to be found and fixed faster.
Looking at your other related question, I notice that you are using Oracle. By using DBI
, you will have a choice between using DBD::ODBC
or DBD::Oracle
under the hood. You can make this choice by simply converting to one of the method parameters DBI->connect
.
If you are using Oracle Instant Client, using it DBD::Oracle
can save you the hassle of downloading / installing the ODBC component on machines that only need Perl access. Of course, removing the ODBC layer from the equation can have benefits as well.
Update
: Win32 :: ODBC is a relatively straight forward conversion of the ODBC middleware API from C to Perl. If you want to limit yourself to ODBC connections on Windows, this has a relatively small advantage in that you have more direct control over the ODBC middleware layer that controls your underlying database. This, of course, does not mean that the ODBC API is particularly faithful to the API and / or capabilities of the underlying database.
Again, assuming you are using Oracle, you seem to have 3 options:
-
Win32::ODBC
→ ODBC → Oracle Driver for ODBC ~> Oracle Client → Oracle Server -
DBI
→DBD::Oracle
~> Oracle Client → Oracle Server -
DBI
→DBD::ODBC
~> ODBC → Oracle Driver for ODBC ~> Oracle Client → Oracle Server
Where "~>" is to the right of the layer that must "fit" one API to match another.
Now I can understand if you want to find the correctness of the API for ODBC middleware. Personally, I would have preferred the flexibility DBI
and shorter software stack used DBD::Oracle
. Though I also assume that a longer stack including DBD::ODBC
will satisfy 99% of all needs, even with two layers of spacer.
Another difference between DBI
and Win32::ODBC
is that there are many modules built around the stack DBI
. The complete namespace depends on this DBIx
. Search for each of these modules on metacpan.org and click the "reverse dependencies" link on your page and you get a pretty sharp picture of the relative value that the Perl community has assigned to each.
So, if you want an additional, purely selfish reason: a Perl developer with DBI experience will also be in much more demand. Seriously.
source to share