| On the Web, the www. sourceforge .net site hosts about 30 myriads of open source projects. One day we extracted the projects in sourceforge's category "DBMS Front End" and looked to see what the vendors were using to communicate with the DBMS engine. Table 12-1 shows the results. As you can see, Table 12-1 shows that, as an API for DBMSs, ODBC is the clear leader. It's been #1 since Microsoft brought out ODBC 1.0 in August 1992. The other APIs ( especially JDBC) have their niches , and we'll certainly talk about them later in this book. But in any discussion of database programming, the ODBC API should get pride of place, and that's what we'll talk about in this chapter. Table 12-1. APIs Used by DBMSs | API | Number of Projects | | ODBC | 62 | | JDBC | 45 | | Oracle OCI | 11 | | OLE DB | 6 | | ADO | 2 | | DAO | 2 | | RDS | 1 | | SQL DBI | 1 | | Other | 4 | Several years ago, Microsoft lost enthusiasm for ODBC, so we don't expect major enhancements to ODBC from that quarter. As a result, there has been some uncertainty about its future. Let's clear that up: ODBC is doomedbut the core of ODBC will prosper and progress for years. There are several reasons why this is true and certain: -
ODBC is native. If you look in the documentation for IBM, Ingres, and Microsoft, you'll find that every one of these vendors claims to run ODBC natively. The word "native" means "no public API is beneath this API"and that's a good thing. (By contrast, the Oracle ODBC driver is non-native because it has to call Oracle's true bottom layer, the Oracle Call Interface.) In general, a native API is a good thing because there can be no finger pointing when a problem comes along. Sometimes it's also suggested that a native API is inevitably faster than a non-native API, but that's falsethe cost of pushing parameters on a stack and issuing an assembly language CALL statement is too trivial to be worth considering. -
Core ODBC is standard. The ANSI/ISO SQL Standard document (SQL/Call-Level Interface ISO/IEC 9075-3) describes an interface that is, to all effects and purposes, the same as core-level ODBC. Yes, there are differences; yes, the differences could grownevertheless, the fact remains that Microsoft doesn't own the specification that people actually use and depend upon. If you looked at a program written with the IBM API, you'd exclaim: "But this is an ODBC program!" To which the comebacks would be: (a) No it isn't, because ODBC is a Microsoft trademark; (b) No it isn't, because it contains some IBM-specific enhancements; (c) Yes it is, because it adheres to the SQL/CLI Standard, and the differences between SQL/CLI and ODBC are less than the differences between, say, Borland C and Microsoft C. -
Microsoft is aboard. Microsoft has only recommended its newer methods as better, without ever threatening to pull the plug on ODBC. Microsoft too says that one can run ODBC natively and is committed to aligning ODBC with the SQL:1999 Standard. |
