The History of ADO

I l @ ve RuBoard

Let's begin this chapter by looking at how ADO has evolved.

ODBC

We met ODBC in Chapter 6, "PHP and Databases." To review, ODBC (Open Database Connectivity) presents a standard way of allowing an application to connect to and work with a database. ODBC presents a middle layer for database connectivity. Your application uses ODBC commands to connect to and query the database, and ODBC then translates these commands to commands specific to your database vendor. To connect to and query a database either directly or using ODBC, your application needs some means of accessing the necessary APIs. Microsoft created its first group of APIs with DAO.

DAO

Data Access Objects (DAO) was a collection of OLE objects that wrapped around the APIs for using the Microsoft Jet engine. The Jet engine is the engine that Microsoft Access uses. Because the DAO objects mirrored objects within a Microsoft Access database (such as tables and queries), DAO provided the quickest and simplest means of accessing Access databases.

However, DAO suffered when used with other databases via ODBC. The Jet engine had to translate the DAO objects into ODBC and from ODBC into queries your database could understand. If it was a database other than Microsoft Access, often a lot of functionality was lost, because many objects could not be translated to ODBC, and the performance was not good.

DAO also suffered when it came to remote data sources such as SQL Server. To operate in a correct client/server fashion, data retrieved from the database is phrased first on the server, and then the client receives only the data it requested . However, DAO pulled all the data to the client so that the Jet engine could parse the data.

RDO

Remote Data Objects (RDO) came next . They overcame the problem of accessing remote data sources. RDO was a new set of COM objects that reflected ODBC APIs rather than Jet APIs. Because ODBC was used, no translation beyond ODBC translation was needed, so RDO operated a lot faster than DAO.

ODBCDirect

ODBCDirect came next. It was introduced into the DAO COM objects. ODBCDirect in fact used RDO to connect and query a database rather than using ODBC APIs directly; however, it gave DAO objects a way of accessing a database without the need to go through the Jet engine.

OLE DB

Microsoft was aware of several RDO shortcomings. Although it provided a set of COM objects for accessing databases via ODBC, it was limited when accessing Jet or ISAM data sources.

The solution Microsoft provided was OLE DB. OLE DB not only wrapped around the ODBC APIs, but it also provided its own API so that database vendors could write OLE DB drivers for their databases. OLE DB also provided you with the means to connect to and query these databases.

ADO

Unfortunately, OLE DB was very tricky to work with. To simplify this, Microsoft introduced Active Data Objects (ADO). ADO is a set of COM objects that wrap around OLE DB to simplify writing code to connect to and query a database using OLE DB.

ADO.NET

Chapter 7, "PHP, COM, and .NET," looked at how Microsoft .NET is evolving. ADO.NET is a part of the .NET framework and, like the .NET framework, does not use COM as its basis. Here Microsoft has redeveloped data access once more, this time to take advantage of common classes, to be easier to work with, and to be more available to .NET programming languages. ADO.NET still provides a wrapper for OLE DB should you need to work with it. However, it is much richer in functionality (for example, you can work with XML data) and for the first time provides database vendors with a way of writing drivers that can be accessed directly by ADO.NET. This is doing away with OLE DB.

I l @ ve RuBoard


PHP Programming for Windows
PHP Programming for Windows (Landmark (New Riders))
ISBN: 0735711690
EAN: 2147483647
Year: 2002
Pages: 99

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net