Databases Reference
In-Depth Information
• They need to be cognizant of what means are available for invoking
these constructs from external applications.
Of course, the syntax for performing the former task is accomplished by
a data query language that is now universal across different computer
systems — SQL. SQL is neither difficult to learn nor use; rather, it is the
means of using SQL in programs that, until recently, presented the greater
challenge.
At first, many database applications were developed by making Open
Database Connectivity (ODBC) Application Programming Interface (API)
calls. But despite all that Microsoft's ODBC allowed you to do, it wasn't
without its own problems. Chief among these were the following:
• ODBC was written exclusively in the C programming language, so
there was no concept of objects or methods. The logical organization
that is intrinsic to Object Oriented Programming (OOP) was nowhere
to be found, resulting in a great deal of frustration when you were try-
ing to find the right procedure or function to call.
• The API was extremely large, hard to follow, and required a fair amount
of knowledge on the part of the programmer.
These shortcomings were noted and Microsoft proceeded to create sev-
eral object models that programmers could use instead. These new collec-
tions of objects and methods were ODBC wrappers; they encapsulated
calls into the ODBC API and hid the implementation details from the pro-
grammer. They exist today in the form of Data Access Objects (DAO),
Remote Data Objects (RDO), and the more recent ActiveX Data Objects
(ADO), as illustrated in Exhibit 34-1.
Then came Sun Microsystems and the rise of Java. Java made many new
promises, but what made it so attractive was that it was designed to offer
Application
DAO
RDO
ADO
OLE DB
ODBC
Non SQL Data
SQL Data
Mainframe
and Legacy
Data
SQL
Jet
Server
Oracle
Mail
Video
Directory
FoxPro
Other
Text
Other
Services
Exhibit 34-1. Comparison of ADO, DAO, and RDO.
Search WWH ::
Custom Search