Many years I am working with MS technology. Using different technique & technology (Microsoft) I am doing my all data access work from different data store. Now Microsoft introduces a new data access technique call Entity Framework. One day I was working with that suddenly I through, what was the past MS data access technology. Then I read some book, article and go through MSDN for MS data access path way. So, I like to share that with all of you.
.NET Framework has provided a platform for developer to develop complex applications that meet up variety of business problem. Those applications bring with it the need to access and manipulate an equally diverse array of data sources and formats. The rise of internet and the computer environment built on much more abstract format.
At release of SQL Server 1.0 at 1989, Microsoft has taken lead role in providing developers with necessary tools to develop database applications. Providing a wide range of adopted set of APIs and COM implementation that database vendors could implement, Microsoft has made it possible for several thousands of data sources to be access via a uniform set of data access client.
Open database connectivity
After the release of MS SQL Server product that was develop in tandem with Sybase SQL Server. Microsoft realizes the issues of providing a standard method of connectivity that allow developers to utilize the SQL server from their applications. To address this need, Microsoft, IBM and a number of other manufacturers teamed up to develop a standard API that would simply the interoperability between their various product. As result Microsoft was provide that was called Open Database Connectivity API or ODBC. This allowed developers much more freedom to develop their application selecting different database. They were not trying to themselves into extremely proprietary and cryptic API, and possibility existed for changing database without a major rewrite of API specific code.
Problems arise: The primary drawback of using ODBC was not easy to use a low-level API such as ODBC to provide data access. Beside that the existence of a standard API for direct data access to all sources meant a much more standardized development community.
Visual Basic 3.0
Corporate level is begun adapt visual basic with release of VB 3.0 in 1993. Microsoft first time introduce Visual Basic developers with a method to easily connect various data sources and build much more robust, data driven applications. Two primary technologies that made this possible were jet database engine and a revolutionary new object model called Data Access Objects.
Jet database engine
The jet engine was initially developed as core database engine for MS Access database. Until the release of VB 3.0 this engine is specific for MS Access database and never use for any other MS products. Microsoft release a new version of Jet engine that allow developers to utilize the service that provide by Jet to interact with any data sources that provided by an ODBC driver. Jet Engine was providing a perfect tool for developers to use data from any ODBC data source without having resort to low-level API programming. The initial focus of the jet was on ISAM (Index sequential Access Method) databases such as MS Access or DBase. Those database does not support or have not feature which is available in large, enterprise RDBMS such as store procedure or server-side query.
Problems arise: One the primary problem of early adoption of jet engine was it size, which take more than megabyte in memory during use. Due to power lacking this was a heft chuck to bite off your standard database application. Beside jet engine provide a thick layer between the client app and database that served to add a large amount of over head to even the most basic database function. Another serious architecture drawback was that all query processing occur on client machine. Jet did not provide the facility to take advantage of server-side queries.
Data Access Objects
Because of DAO (Data Access Objects) VB 3.0 and Jet engine 1.1 was gained such large number of acceptance. DAO was provided a simple and flexible method for connection and manipulating data in any data source compatibility with jet. DAO was provided simplicity of data access through DAO structure so that VB developers allowed developing more robust and powerful database driven application. Not only just a standard object model but also it provided a platform for third party vendors to begun into developing which lead toward a huge market of data-bound control and widgets. Worldwide Million of VB developers utilized DAO as a power data-access tool.
Visual Basic 4.0
Visual Basic popularity was just rock after the release the VB 3.0 and its data access tools at corporate world. So, Microsoft addresses the issue of those tools architecture and functional limitation they imposed. With the next release of VB 4.0 Microsoft extended the functionality of those tools and also provided two new database-access methods to take advantage of full RDBMS systems.
VBSQL
VBSQL support VB developers to connect directly to SQL Server Database using its low-level API. This API, built around the C-Based DB-Library, provided a lightweight and high speed interface that was easy to code when using VB.
Problems arise: VBSQL only for SQL Server database which did not have a significant market share in early ‘90s. Beside that time object-oriented and database-neutral methods fro database access become available, as also developers become less interest to code directly in a database API.
Remote Data Objects
VB 4.0 was also included a new data-access object that was called RDO. RDO was solved the problem that was facing by developers during develop a large distributed client-server applications with DAO and jet. Comparing with DAO and jet, RDO provided much smaller and faster client-side object.
Problems arise: RDO provide as a thin object interface directly to the underlying ODBC driver. The RDO consists only 10 objects compare to 17 objects in DAO.
OLEDB
In late 1996, Microsoft announced new next key technology in its quest for a unified data access paradigm. OLEDB was built on MS new COM architecture. OLEDB methods focused on presenting data in a standard format. OLEDB was based on underlying idea of implementing data provider and data consumer. With OLEDB, Database vendors provide high performance providers implemented as COM object. These providers organize their underlying data into a consistent view of data and the make this data available as tables. Other the data was aggregated into this common view, data consumers could be developed to provider a consistent interface to this data. By providing the capability to display both structure and unstructured data in a common format. OLEDB allows consumers to use a standard syntax such as SQL. OLEDB provider increase significant performance comparing the old ODBC. Microsoft could not just ignore the exits ODBC driver on market, so an attempt to help speed adoption of this new data access technology, Microsoft first build OLEDB provider for ODBCdriver.
Visual Basic 6
OLEDB has been successfully standardizing on OLEDB provider as core technology for interacting with any type of relational or non-relational data stores. Now Microsoft next step will be provide data consumer which would have build on standard OLEDB provider.
ActiveX Data Object
In 1996, OLEDB consumer, ADO has become most popular object-oriented, data access technology. ADO 1.0 was initially used to develop web sites with ASP. Microsoft released a single data access package called Microsoft Data Access Component (MADC) that contained both its current OLEDB provider and ADO objects. ADO provides developers the capability to query and manipulate data from any OLEDB complaint provider. The lack of deep object hierarchy is the main different between ADO object models and either DAO and RDO. ADO developers are allowed to access the data using RDO Recordset-type objects, which allow them to create and manipulate providing the functionality such as Remote Data Service, disconnected Recordsets and XML-based persistence. ADO object has evolved over the few years to help address the growing disconnected nature of the internet.
Recordsets
Recordsets object provides primary interface when using ADO to interact with a database, effectively serving as a developer’s window into data store. All data manipulation using ADO occurs through this window. ADO subsystem handles all the process to make sure that all the changes are made back to the database. Recordset object allows manipulating a subset of data from database. Each Recordset object consists a set of rows and columns that we can traverse to get or set the information we need.
Problems arise:
The ADO Recordsets object simply manipulates all the data values as variant type. That gives a huge amount of flexibility and neutrality. But this provides ADO Recordsets with its biggest performance hit.
When dealing with all Microsoft’s previous implementations of data access technology, it is most important to understand that they all are tied to Microsoft windows platform. Both the object models and the ODBC drivers or OLEDB providers that serve up the data are tied to Windows-specific implementations.
I am tried to put all the past Microsoft data-access technology before ADO.NET in here with very little description. Please let me know if I miss some of the part. Thanks for you time to read this.