Evolution of ado+-guided data types (transfer from MS one)

Evolution of ado| Data ado+ Guide data types
Dino Esposito
September 2000

Summary: This article discusses the enhanced interoperability and scalability offered by the latest version of ADO, ado+.

Directory

Brief introduction
A common data manipulation language
Types of data
What the ado+ added
The constituent elements of ado+
ado+ command
Strongly typed programming
Summary


--------------------------------------------------------------------------------


Brief introduction

From the outset, the software application was developed to access some kind of database. Distributed applications and web-based applications are no exception. However, in a distributed scenario, things are slightly more complex because of the possible existence of different hardware and software platforms or object models. Nevertheless, data is data that needs to be exchanged and processed in almost any place.

Before we entered the third phase of the programmable Web age-internet, data access was a relatively simple issue; The primary concern was to select the most cost-effective database server. All modules of any system must conform to the requirements of the database server-a universal entity that fully controls the entire system. Client/server applications have been a typical manifestation of this model.

Recently, the N-tier Microsoft®windows®dna system is dedicated to the development of technologies that enable fast and reliable access to virtually any kind of data, including relational, non relational, hierarchical, semi-structured, decentralized, and volatile types. This unified approach to data access is an inspiring principle of-ole DB architecture for universal data access policies. The advent of Microsoft activex®data Objects (ADO) has accomplished a major task: bringing thousands of Windows developers from an outdated client/server model to the wonderful world of data access Components and OLE DB.

In the Windows DNA model, the middle-tier component takes care to obtain and exchange data in a common format defined by the OLE DB specification. This format is based on the rowset format and is typically converted to a more advanced structure such as the ADO recordset.

Use ADO recordset gain. On the one hand, they provide a rich and attractive programming interface. On the other hand, they are strictly COM based and cannot be used in distributed heterogeneous environments that involve many platforms, especially non-Windows platforms. Interoperability and scalability are two high requirements for modern Web systems, and a better interoperability and scalability data access architecture is also a major change in the latest ADO version ado+.


--------------------------------------------------------------------------------


A common data manipulation language

In general, the current distributed system conforms to the architecture shown in Figure 1.


Figure 1. The typical architecture of distributed WEB systems at present

The presentation layer is typically based on HTML 3.2 output and can work well with any newer browsers. Web pages are built using Active Server Pages (ASP) on a Web server, and only in some very specific cases are attempts to provide the actual functionality of the browser through COM, dynamic HTML, and XML support.

The key is the middle tier, where one or more tiers of business objects typically acquire and exchange data to respond to user input. These components may need to pass data to each other, and in the process of passing data, they need a common data format that is easy to use, powerful, and understood by all components. ADO recordset-The ADO representation of a table or view-is a pretty good solution, it has several advantages, and has only one big drawback.

The flexibility of an ADO recordset is sufficient to allow you to easily locate records and use filters and bookmarks. They also provide functionality such as sorting, automatic paging, and durability, and can work when disconnected from the data source. The recordset can be pooled fairly efficiently between tiers, thanks to its intrinsic and extremely compact binary format-advanced Data Table Gram (ADTG) format.

The transfer of disconnected recordset between components involves COM collections and forces the receiving component to cooperate with this collection. In other words, only COM objects can use an ADO recordset. This is not a problem in the homogeneous architecture that dominates the com/dcom in the business layer. Obviously, when the mapping of server-side components concerned involves heterogeneous nodes such as mainframes or Unix platforms, it can be a great inconvenience.

The third phase of the so-called Internet has brought this scheme closer to us. It heralds a world in which functional implementations are possible through a variety of WEB services (that is, satellite systems that can be accessed via HTTP). You will need to pass some records to one of these services for further processing, and this scenario is not a grudging thing. Nothing is easier than a WEB service-regardless of its internal architecture or the common programming interface-it does not accept an ADO recordset.

A current reality of ADO, especially recordsets, is a powerful tool for manipulating data in Windows and COM based scenarios. Unfortunately, as your system evolves towards full Internet interoperability, they are losing their appeal.


--------------------------------------------------------------------------------


Types of data

In perfect situations, you should be able to access data in the same way on any platform or device and have the same flexibility. This allows each platform or device to manipulate data freely as needed. If you present data through an ADO recordset, you also expose yourself and your application to the actual risk of limited interoperability.

Currently, if you are accessing data through ADO, and want to deliver it to a remote component, you either use the same ADO recordset that you obtained from the data Access module, or convert it to something that can be transmitted over the network, and more importantly, be understood at its final destination. As mentioned earlier, the recordset requires a COM collection, for example, that COM calls do not always go through the corporate firewall. In addition, when the ADO recordset is pooled, a large part of the total processing time is used to complete the necessary type conversions. In fact, you must make sure that all the values in the record map to valid data types that COM can recognize and know how to process.

COM aggregation factors become more important when the relevant components are physically separate and run on different machines. Therefore, the current type of Windows data, along with the ADO Recordset, must evolve to continue in the process of moving to a world that is fully connected to the Internet.

Do you need an example? In the cutting Edge column in MIND's January 2000 (English) and MSDN Magazine March 2000, I used remote scripting (RS) as a cross-browser to get data from a remote ASP page and not navigate to that page Technology is described. When you call a remote function on a page in this way, the RS infrastructure provides the content returned by the function back to the client. In most cases, you need to return a recordset. However, for security reasons, RS does not even attempt to process an ADO recordset with any other COM object. Thus, if you use RS, you must avoid using an ADO recordset, and you should use an array or string to pass the requested information. In the March 2000 column, I explained this intrinsic limitation by building a JavaScript object from the recordset. The ASP page gets the data through ADO and converts it to a JavaScript object before returning to the calling program:

rst = new ActiveXObject ("ADODB.") Recordset ");
Rst.open ("SELECT * FROM Employees", "Dsn=northwind");
ORS = new Recordset (RST);
Rst.close ();
return ORS;

The client page receives the object when it runs through RS and can process it as needed, much easier than passing a string or array. For more information and source code, please see my March 2000 Cutting Edge column article (in English).

Can we learn anything from here? For data interoperability beyond a single client or server-side platform, we need to make a small change to the ADO model.

We need to change because Cross-platform module interaction requires a common data model. In addition, we do not want this change is too large, because there are several good features in ADO, it is a pity to abandon them.

The JavaScript Recordset object, in terms of its intrinsic simplicity, is just a sign of the number of times. We need to extract the nature of the ADO recordset and reconstruct it as another thing that can be conveniently transmitted and processed on any platform. HTTP provides a widely accepted network channel. XML brings together the infrastructure of widely accepted data descriptions. Ado+ is a minor improvement to ADO, making it a standards-based programming model for creating distributed and data-sharing applications.


--------------------------------------------------------------------------------