The simplest way to implement Remote Data Access on the client is to use a
Data Source Object (DSO) specifically designed for this task. The specification for a DSO is open, and they can be implemented as a variety of languages. Several are either supplied with Internet Explorer and other programming environments, or can be downloaded from the Internet directly. The Internet Explorer Client SDK lists some of these objects and provides more information. We'll look at the popular ones next, then move on to see how they can be used.
Data Source Objects
We can implement Remote Data Access by instantiating a data source object on a Web page in Internet Explorer 4 or higher. The connection is made, and the data is fetched across the network and cached on the client. At this point it can be bound to controls on the page, or manipulated using ADO.
At the time of writing, the following DSOs were freely available, either as part of the IE4/5 installation or as a separate download:
The
Remote Data Service Control, commonly known as the ADC/RDS control.
The
Tabular Data Control (TDC), sometimes referred to as the Text Data Control.
The
JDBC Applet Control, a Java applet providing an alternative to the ActiveX RDS control.
The
XML Data Source Control, both as a Java applet and a C++ ActiveX Control.
The
MSHTML Data Source, implemented internally by Internet Explorer itself.
Also on the way is a new XML Data Source Object from Microsoft, written in C++, which is designed to be used both on the server and the client. And, as we saw earlier in this chapter, Internet Explorer 5 is itself a Data Source Object, in that it can expose XML-formatted data directly as a recordset on the client. This data may come across the network from a separate file on the server, or as a data island within the current page.
Instantiating Data Source Objects
Because each DSO is different, both in their implementation and in the type of data they are designed to access, the way that each one is instantiated varies a great deal. We'll briefly look at each one listed above. The example code shows only a selection of the most useful property settings for each control. A full list of the properties exposed by the RDS and TDC controls, together with all the methods and events, is provided in Appendix E.
The Remote Data Service Control
The
Remote Data Service Control, is designed to connect to a data store through an OLE-DB or ODBC driver. It was originally named the Advanced Data Control (ADC) and is sometimes referred to as the ADC/RDS control in order to avoid confusion over the use of RDS as a control name and RDS as a technology. It can be used to update the source data on the server, and is automatically installed with Internet Explorer 4 and higher:
<OBJECT CLASSID="clsid:BD96C556-65A3-11D0-983A-00C04FC29E33"
ID="dsoBookList" HEIGHT=0 WIDTH=0>
<PARAM NAME="Server" VALUE="http://www.yourserver.com">
<PARAM NAME="Connect" VALUE="DSN=pubs;UID=anon;PWD=">
<PARAM NAME="SQL" VALUE="SELECT * FROM BookList">
</OBJECT>
The code above creates the RDS object and instantiates it. It connects to the server specified in the first
PARAM element, and to the data store specified in the second PARAM element. It then executes the SQL statement specified in the third PARAM element, and retrieves the data into a locally-cached recordset.
Note that the database can be on a different machine from the Web server, and in this case you would specify the server name in the
Connect property as well. In fact, to achieve this, the easiest way is to use a full connection string instead of a DSN. For example, in the following code, the control gets its data from a SQL Server database on a machine named dataserver.com:
<OBJECT CLASSID="clsid:BD96C556-65A3-11D0-983A-00C04FC29E33"
ID="dsoBookList" HEIGHT=0 WIDTH=0> <PARAM NAME="Server" VALUE="http://www.yourserver.com">
<PARAM NAME="Connect" VALUE="SERVER="http://dataserver.com;
DRIVER={SQL Server};DATABASE=yourdb;
UID=anon;PWD="> <PARAM NAME="SQL" VALUE="SELECT * FROM BookList">
</OBJECT>
Note that, on Windows NT4, you can't use Integrated security in the database if it is on a different server to the Web server. This problem will go away with NT5 and the new Active Directory Service. See Appendix E for a full list of the properties, methods and events for this control.
The Tabular Data Control
The
Tabular Data Control (TDC), sometimes referred to as the Text Data Control, is designed to expose a delimited text file as a recordset, and allow data binding and ADO to be used with the text data. It cannot be used to update the source data on the server. The TDC is automatically installed with Internet Explorer 4 and higher.
The code above creates the TDC object and instantiates it. It connects to the text file specified in the
DataURL property and caches it as a recordset locally on the client. The next two PARAM elements specify that each line in the file uses a comma as the field delimiter (FieldDelim), and that the first line in the file is a definition of the field names and types (UseHeader). The default filed delimiter, if not specified, is a comma. The default record delimiter is a carriage return, but it can be changed if required by setting the optional RowDelim property.
Of the remaining parameters, the
Sort property specifies the sorting order of the records. In our example, records are sorted by category ascending then by release date descending (the minus sign appended to the start of the field name indicates descending sort order). The Filter property shown above specifies that only records in which the book code field value starts with '16-1' will be included. Finally the EscapeChar property specifies a character that can be used to 'escape' any characters within a field that are the same as the field delimiter. In the example above, we could use 'XML\;TheFutureForData' as a value in a field, and prevent the control treating the backslash as a field delimiter.
A simple data file for use with the code shown above might look like this:
tCode:String;tCategory:String;dReleaseDate:Date;tTitle:String;nSales:Int
16-041;HTML;1998-03-07;Instant HTML;127853
16-048;Scripting;1998-04-21;Instant JavaScript;375298
16-105;ASP;1998-05-10;Instant Active Server Pages;297311 ... etc. ...
See Appendix E for a full list of the properties and methods for this control.
The JDBC Applet Control
The
JDBC Applet Control provides an alternative to the ActiveX control structure of the ADC/RDS object, and is implemented as a Java applet. This allows browsers other that Internet Explorer to be used with your remote data applications. It connects to a data store through an ODBC driver - via a client-side DSN previously set up in Control Panel - and can be used to update the source data on the server. However, this requirement for an existing DSN prevents a 'hands-off' automatic download and install of the applet in a page, as happens with most other Java applets.
The control and information on using it can be downloaded from Microsoft's Web site at
Since a value for the cabbase parameter is provided, which specifies the location of the code for the applet, it will be downloaded if not already installed on the client machine. The remaining parameters define the properties to be set when the control is instantiated.
The dbURL property identifies the ODBC data source name (DSN) to use to connect to the database, and the showUI property specifies that the control should not display a user interface. The sqlStatement property is set to a SQL string that will extract the data from the database. The user and password properties can be set to the details of the account required to access the data, if this information is not provided by the DSN. As the control is running on the client machine, this DSN is a File DSN previously set up in the user's ODBC dialog available from Control Panel.
The remaining properties define how the data exposed by the control can be used, by controlling whether the code in the page can insert new records, or delete or update existing records.
The XML Data Source Control
The
XML Data Source Control is available as a Java applet or a C++ ActiveX Control, and both can be downloaded as a complete package (including samples) from http://www.microsoft.com/xml/parser/xmlinst.exe. These DSOs provide read-only access to a client-based or server-based file that holds data in XML format. They allow data binding and ADO to be used to view the data.
The code to instantiate the Java Applet uses the normal
The CODE attribute specifies the package in which the code is implemented, which is defined in the user's Registry. Once instantiated, the control loads an XML-format data file from the location specified in the URL parameter, parses it, and makes the data available as a locally cached recordset.
The C++ DSO is instantiated using script. The following is a sample in JavaScript. It creates the object, then sets the url property to the XML file that we want to parse and display:
<SCRIPT LANGUAGE="JavaScript">
dsoBookList = new ActiveXObject("msxml");
dsoBookList.url = "booklist.xml";
</SCRIPT>
A simple XML-format data file might look like this:
This screenshot shows the result of using the Java XML DSO in conjunction with some data-bound controls on the page. We'll be looking at the techniques for data binding later in this chapter.
The MSHTML Data Source Object
The
MSHTML Data Source is implemented internally by Internet Explorer itself, being part of the browser. It allows the contents of a client or server-based Web page to be exposed as a read-only recordset, used with data binding, and manipulated with ADO. To instantiate the data control just requires the DATA attribute of an <OBJECT> element to be set to the URL of the HTML page containing the data:
<OBJECT ID="dsoBookList" DATA="/data/booklist.htm" HEIGHT=0 WIDTH=0>
</OBJECT>
Once the control is instantiated, it loads the page defined in the
DATA attribute and exposes it as a locally cached recordset. The values that form the content of the records are identified by their ID attribute in the source Web page. It doesn't matter what the actual elements that hold the data are, as long as they have both opening and closing tags. Their ID attribute value defines the field that they hold data for.
In other words, the following two HTML elements define a single field recordset with two records. Each record would hold the title of a book:
<H3 ID="BookTitle">Instant JavaScript</H3>
<SPAN ID="BookTitle">Instant Active Server Pages</SPAN>
However, it's usually more useful to use the same type of element for each value for a particular field. A simple data file for use with the MSHTML control might look like this:
The great thing with this technique is that we can include HTML in the page to make it look OK on other browsers, or when loaded directly into IE. This extra code has no effect on the data control, and any formatting inside the elements that define the field values just becomes part of the field value:
The next screenshot shows the result of using the MSHTML DSO in conjunction with a data-bound HTML table in the page. We'll be looking at the techniques for data binding later in this chapter:
Other Data Source Objects
Microsoft provides a new Data Source Object with Internet Explorer 5, a
UniversalXML DSO written in C++. This can be instantiated on both the server and the client, and is used to build the kind of XML-based applications we discussed earlier in this chapter.
At present the technology is still developing, but the new XML DSO provides a host of opportunities to build platform-independent applications. If the communication between the server and client is pure XML, in a universally agreed format, then any suitably equipped client will be able to communicate freely with any XML compliant server-based DSO.
