| |||||||||||||
| |||||||||||||
|
| |||||||||||||
| |||||||||||||
|
| |||||||||||||
| |||||||||||||
The Perl DBI Architecture can then be seen as being split into a number of distinct layers.
| The Program Layer The Program Layer consists of the Perl code that makes calls to the DBI API Methods. |
| |||||||||||||
|
| ||||||||||||||
| The API Layer The DBI passes method calls from the Perl script to whatever driver has been specified in the connection string. |
| |||||||||||||
|
| ||||||||||||||
| The Driver Layer The Driver Layer contains protocol drivers that implement various DBI methods using private interface functions. |
| |||||||||||||
|
| ||||||||||||||
| The Database Layer The Database Layer consists of the actual database engines such as Oracle, MySQL, etc. |
| |||||||||||||
The Perl DBI Architecture is essentially similar to ODBC (the Open Database Connectivity). The ODBC equivalent of the Perl DBI is the ODBC Driver Manager, and the ODBC Drivers are the equivalent of Perl DBD drivers. A number of Perl DBI modules exist for ODBC use, e.g. DBD::ODBC (written in C) and Win32::ODBC (written in C++).
The ADO (ActiveX Data Objects) is yet another Microsoft Layer built on top of a layer. Essentially, ADO is a data access API, and in a Microsoft environment, works fine as another layer on top of ODBC. Access to Microsoft databases such as SQL Server is not onerous using ADO, however as with a number of other Microsoft technologies, they are dependent on all layers working, and unfortunately, unlike Perl and DBI, the level of robustness in the Microsoft technologies is less impressive. The other drawback is during the debugging process. The more layers in the system, frequently the harder and longer it takes to resolve issues with the code.
It is however, possible to use ADO from Perl by using the Win32::OLE module and even better, the DBD::ADO module.