By Rick Dobson
Active Server Pages (ASP) technology is a powerful Web server feature. It supersedes the Internet Database Connector technology, which Microsoft no longer officially supports. In brief, ASP allows developers to mix HTML and a scripting language in a single file; developers can control how the server interacts with browsers through scripting. Microsoft introduced ASP with Internet Information Server (IIS) version 3. You can also use ASP with Personal Web Server for Windows 95, and Peer Web Server for Windows NT Workstation.
This all sounds fine, but as a Visual Basic for Applications developer, you may be wondering what it has to do with you. There are at least four reasons for VBA developers to gain proficiency with ASP:
VBScript, a subset of VBA, is one of two default scripting engines that ship with ASP. Therefore, VBA developers already have a basic understanding of one of the core ASP techniques.
A wizard that ships with Access 97 vastly simplifies publishing to the Web in ASP format. Using this wizard, content authors can create dynamic pages that link directly to Access databases. Whenever the database updates, the page can instantly reflect the revision without any additional effort on the part of a Webmaster.
Developers can also use the wizard to publish parameter queries that work over the Web. This capability drastically improves the availability of Access databases, because users can query them with a browser over the Web. Users don't require a copy of Access to accomplish this.
Developers can publish Access forms over the Web with the wizard.
This is the first of a four-part series on Active Server Pages. This installment introduces selected ASP components that relate to Access databases. It goes on to describe how to publish pages over the Web that dynamically link to Access datasheets. Finally, it discusses the steps for publishing Access parameter queries over the Web.
Things to Know Before You Publish
When using ASP to work with Access databases over the Web, you'll find it valuable to become familiar with three enabling technologies:
Get a working knowledge of HTML. Novices can visit http://msdn.microsoft.com/workshop/author/plan/novice-f.htm. This page points to several additional resources.
It's very useful to know VBScript. This VBA subset contains essential VBA syntax, statements, and functions for scripting over the Web. It leaves out as much as possible to support fast and efficient operation. The ASP documentation includes primers on VBScript and JScript, its other native scripting language.
Learn about linking to ODBC data sources. When working over the Web with Access databases, you'll work with Access through an ODBC driver. This requires a data source name — or DSN — that can link a request from a browser to a specific Access database.
Five built-in objects support many standard and advanced Web-server functions. The Request object supports getting information from users. The Response object facilitates sending information to users. The Server object supports a broad range of Web server features, including the database access component. This component uses ActiveX Data Objects (ADO) to process ODBC data sources, such as Access databases. The Session and Application objects permit ASP developers to maintain state for individual users within a single Web session, and across multiple users for a common Web application, respectively. These objects overcome the stateless Web-programming interface in which developers have no more information than what is on the current page.
Access developers who view and edit ASP pages will benefit particularly from familiarity with the Request object. Five hierarchical object collections belong to the Request object, but the QueryString and Form collections will be of most interest to developers working with Access databases. You'll typically use the QueryString collection to parse information sent to a Web server in the URL, such as with the Get method. The Form collection supports processing data sent to the server with the Post method.
The QueryString collection can parse a URL such as:
http://myServer/myFolder/UpdateMyDB.asp?name=Rick+Dobson
The following code returns the value of name — an input text box on an entry form — with a short greeting:
Welcome, <%= Request.QueryString("name") %>.
The angle brackets and percent signs delimit the reference to the ASP object from the rest of the HTML on a page. The browser "sees" this statement as:
Welcome, Rick Dobson.
When an HTML form passes its information to a server with the Post method, developers should use the Form object to parse the input from the browser. The following line extracts the value from name.
Welcome, <%= Request.Form("name") %>.
The form uses the Post method to send its contents to the server. If the user types Bill Gates in the text box, then it returns:
Welcome, Bill Gates.
Active Server Pages are an integral part of IIS version 3+. It ships with its own documentation, which developers can view with a browser. FIGURE 1 shows a sample page with a menu of topics on the left, and an explanation for the selected topic on the right. The text describes the role of ADO in ASP. The Show Me button allows those taking the ASP tutorial to interact with it. Clicking the button will populate the table below it with values. The documentation also contains many code segments that you can adapt for your custom ASP applications.
FIGURE 1: A sample screen from the ASP documentation. Clicking the Show Me button populates the table with values.
If you are not running IIS version 3+, you can download ASP, with the following steps, to Personal Web Server for Windows 95:
Navigate your browser to http://backoffice.microsoft.com/downtrial/moreinfo/iis3.asp.
Complete the Registration form on the IIS 3.0 Download page
On the Choose the IIS 3.0 Features You Would Like to Download page, clear the check boxes for all components except Active Server Pages, and select the correct language version. Click Next.
Pick a download location.
On the Click On Each Item Below In Turn to Download page, click the ASP link to open or download Asp.exe, and install ASP.
After downloading and running the installation program, you can check if it installs correctly. Open the application with the Start button; choose Active Server Pages Roadmap. Click the More Samples hyperlink from the right panel. Then, click the ADO using Server.CreateObject hyperlink. If these actions return a table, the installation worked.
Using Access 97 to build ASP applications requires something that ties your pages to a data source. One way to do this is with a system DSN that points at your Access database. If you are the system administrator on your Web server, you can create a system DSN with the 32-bit ODBC icon in your Control Panel. Otherwise, have your administrator create the system DSN. Remember the DSN name; you will need it for a built-in wizard that simplifies publishing to the Web.
There are two types of DSNs that concern us: file and system. A file DSN stores the information for connecting with a database in a file, in contrast to a system DSN which is stored in the system registry. With a file DSN, you do not have to ask the administrator to create a system DSN for you. If you are the administrator, you can have folks create their own DSNs without your involvement. This removes the need for an administrator to create multiple DSNs for everyone who wants to create Web pages with database access.
You can create a file DSN with the 32-bit ODBC icon on the Control Panel. Be sure to choose the File tab, instead of the System tab. After creating the file DSN, copy it and the Access database to the same folder on your Web server. File DSNs have a "dsn" extension. By default, the 32-bit ODBC icon creates the file DSN in the \Program Files\Common Files\ODBC\Data Sources folder. Copy your file DSN and your Access database to a virtual directory on the Web server to which you have write permissions. Then, use the built-in wizard for Web publishing as you would with a system DSN (see below). However, do not specify a data source. Later, edit the wizard-generated ASP file so that it points at the file DSN. Microsoft Knowledge Base report Q167294 (http://www.microsoft.com/support/kb/articles/q167/2/94.asp) includes detailed instructions for editing the ASP file. FIGURE 5 shows the outcome of these instructions for the Northwind database.
Access can represent the contents of tables, queries, and forms over the Web by publishing datasheets. Recall that a datasheet is simply a row-and-column display of the entries in a table, the answer set from a query, or the data underlying a form. With ASP and the Publish to the Web Wizard, developers and content authors can publish tables, queries, and forms to the Web so that changes in a datasheet instantly appear as datasheet-linked pages are browsed. This style of publishing is different from static publishing in which pages do not change until you create them again.
The Publish to the Web Wizard automatically constructs a separate ASP file for each datasheet you select. While you can re-run the wizard, it is desirable to learn the structure of the ASP file so you can perform light editing. HTML editors such as FrontPage Express make it possible to improve the appearance of a published datasheet with greater variety, flexibility, and ease than with the wizard. However, every time you re-run the wizard, you lose any editing that you perform by another means, such as with an HTML editor. I recommend, therefore, that you re-run the wizard until you get an ASP page that reflects your basic data-display needs. Then, format the table and page with an HTML editor. Perform manual editing to the ASP script to implement minor page revisions. This preserves the formatting. An additional reason for learning the structure of the ASP file is so that you can make the changes necessary to reference a file DSN.
Invoke the Publish to the Web Wizard by selecting File | Save as HTML. The first screen allows you to invoke a previously-saved publication profile. These are useful if you find yourself repeatedly making nearly identical choices on successive runs of the wizard. You should avoid using this feature until you find the set of wizard selections that best meets your publication requirements.
The next screen (see FIGURE 2) allows you to pick one or more database objects to publish dynamically. Four tabs — Tables, Queries, Forms, and Reports — group all database objects you can publish. A fifth tab — All Objects — gives you ready access to all these database objects. When publishing dynamically, do not choose objects on the Reports tab. The wizard publishes these exclusively in static format.
FIGURE 2: The Publish to the Web Wizard lets you select one or more database objects to publish.
The third wizard page lets you choose a template with which to format the publication. This can be handy if you want to automatically include a company logo and other standardized formatting on a large number of pages. If you are publishing a relatively small number of pages each time you use the wizard, you may find it as easy to do manual formatting of a few ASP files with an HTML editor.
The fourth screen (see FIGURE 3) allows a content author to choose a publication format. Dynamic ASP is the option to select if you want to create ASP files. If you select more than one database object to publish to the Web, then you can select formats that best serve the needs of each database object. You might use a static format to publish a course catalog that will be updated only at regular publication cycles (e.g. each semester). You may prefer to publish your customer or employee datasheets in a more dynamic format. This will allow those working with customers or employees to view the most recent additions and changes to the tables.
FIGURE 3: The Publish to the Web Wizard lets you select a publication format, such as Dynamic ASP.
The fifth screen allows you to specify a system DSN. Recall that you create this before invoking the wizard. The system DSN should exist on the Web server. This DSN will point to an Access database, either on the Web server or on a computer connected to the server via a LAN. If you choose to use a file DSN, then you should leave the Data Source Name text box blank. Doing this will require you to manually edit the ASP file before using it. When you dynamically publish datasheets, leave all other text boxes on this screen blank.
The sixth screen allows you to specify a folder for storing your wizard-generated ASP files. When I'm working on an intranet, I find it most convenient to deposit my ASP files in a virtual directory on my Web server. Since ASP files contain scripts, you will want to assign Execute Scripts permission to the folder. Unless you want visitors to be able to read your scripts, you will probably want to deny Read permission for the folder. When I work with a FrontPage Web site on the Internet, I collect the ASP files in any arbitrary folder on my computer. After generating and formatting all my pages, I use FrontPage to transfer the ASP files to a folder on the site with Execute Scripts permission.
The seventh screen lets you create a home page. I prefer to manually generate a home page with an HTML editor instead of using the wizard-generated home page. In addition to not generating a particularly attractive page, the wizard's home page will become obsolete unless you re-generate all your pages each time you use it.
The eighth and final wizard screen lets you save your choices as a publication profile. This capability has more value for static publications that you will re-run on regular cycles. Because dynamic publications update automatically, you will not typically re-run them on a regular cycle.
FIGURE 4 shows the ASP page in a browser window. The browser appears to show the ASP file in the Address list box. One important point to note is that the output appears as an HTML table. Furthermore, it looks like a standard HTML table when viewed with the browser's View Source command. On the Web server, the ASP file exists as a script with HTML formatting options. The script navigates through an ADO recordset to propagate values in the table. Then, the Web server sends the fully populated table to the browser.
FIGURE 4: The Customers table from the Northwind database, in a browser. Notice that FIGURE 2 shows this table selected.
On the server side, you can conveniently divide the script and HTML in the ASP file into three components. FIGURE 5 shows the initial component. The script begins by creating a connection with the Access database. Then, it generates an ADO recordset based on the connection. The code uses SQL and the ASP Server object to generate the recordset.
FIGURE 5: The ASP code to link to the database and create an ADO recordset. This example illustrates the use of a file DSN.
<%
Param = Request.QueryString("Param")
Data = Request.QueryString("Data")
%>
<%
If IsObject(Session("_conn")) Then
Set conn = Session("_conn")
Else
Set conn = Server.CreateObject("ADODB.Connection")
conn.open "FILEDSN=c:\program files\microsoft office\" + _
"office\samples\myFileDSN.dsn","Admin",""
Set Session("_conn") = conn
End If
%>
<%
sql = "SELECT * FROM [Customers]"
If cstr(Param) <> "" And cstr(Data) <> "" Then
sql = sql & " WHERE [" & cstr(Param) & "] = " & cstr(Data)
End If
Set rs = Server.CreateObject("ADODB.Recordset")
rs.Open sql, conn, 3, 3
%>
FIGURE 5 illustrates how to use a file DSN. It was necessary to edit this code after leaving the Data Source Name text box on the fifth wizard screen blank. I adapted the Microsoft Knowledge Base report Q167294 instructions for the Northwind database. The file DSN resides along with the Northwind database in its normal location, namely the C:\Program Files\Microsoft Office\Office\Samples folder.
The next code segment (see FIGURE 6) illustrates the code heading that sets up the table heading for the Customers table that appears in FIGURE 4. Notice that it's straight HTML. The heading appears in a <THEAD> block that houses a <TR> block. The row block includes a series of cells delimited with <TH> tags. Each of these cells contains an individual heading, such as Customer ID or Company Name.
FIGURE 6: The ASP code to create the table heading for the Customers datasheet that appears in FIGURE 4.
<TABLE BORDER=1 BGCOLOR=#ffffff CELLSPACING=0>
<FONT FACE="Arial" COLOR=#000000>
<CAPTION><B>Customers</B></CAPTION>
<THEAD>
<TR>
<TH BGCOLOR=#c0c0c0 BORDERCOLOR=#000000 >
<FONT SIZE=2 FACE="Arial"
COLOR=#000000>Customer ID</FONT></TH>
<TH BGCOLOR=#c0c0c0 BORDERCOLOR=#000000 >
<FONT SIZE=2 FACE="Arial"
COLOR=#000000>Company Name</FONT></TH>
<TH BGCOLOR=#c0c0c0 BORDERCOLOR=#000000 >
<FONT SIZE=2 FACE="Arial"
COLOR=#000000>Contact Name</FONT></TH>
<TH BGCOLOR=#c0c0c0 BORDERCOLOR=#000000 >
<FONT SIZE=2 FACE="Arial"
COLOR=#000000>Contact Title</FONT></TH>
<TH BGCOLOR=#c0c0c0 BORDERCOLOR=#000000 >
<FONT SIZE=2 FACE="Arial"
COLOR=#000000>Address</FONT></TH>
<TH BGCOLOR=#c0c0c0 BORDERCOLOR=#000000 >
<FONT SIZE=2 FACE="Arial" COLOR=#000000>City</FONT></TH>
<TH BGCOLOR=#c0c0c0 BORDERCOLOR=#000000 >
<FONT SIZE=2 FACE="Arial"
COLOR=#000000>Region</FONT></TH>
<TH BGCOLOR=#c0c0c0 BORDERCOLOR=#000000 >
<FONT SIZE=2 FACE="Arial"
COLOR=#000000>Postal Code</FONT></TH>
<TH BGCOLOR=#c0c0c0 BORDERCOLOR=#000000 >
<FONT SIZE=2 FACE="Arial"
COLOR=#000000>Country</FONT></TH>
<TH BGCOLOR=#c0c0c0 BORDERCOLOR=#000000 >
<FONT SIZE=2 FACE="Arial" COLOR=#000000>Phone</FONT></TH>
<TH BGCOLOR=#c0c0c0 BORDERCOLOR=#000000 >
<FONT SIZE=2 FACE="Arial" COLOR=#000000>Fax</FONT></TH>
</TR>
</THEAD>
The final code excerpt (see FIGURE 7) from the ASP file populates a table with values. Notice that it inserts short VBScript segments in angle brackets and percent signs. A Do Loop statement navigates through the recordset created in the first component. The HTML represents a single row for the table. The script populates this row with new values on each pass through the Do Loop. Within each cell of the row, there is a call to a server-side function that encodes the recordset characters before inserting them in the HTML page that the Web server sends to the browser. This ensures they will be appropriate for viewing by a browser.
FIGURE 7: The ASP code to create the table body for the Customers datasheet that appears in FIGURE 4.
<TBODY>
<%
On Error Resume Next
rs.MoveFirst
Do While Not rs.eof
%>
<TR VALIGN=TOP>
<TD BORDERCOLOR=#c0c0c0 >
<FONT SIZE=2 FACE="Arial" COLOR=#000000>
<%=Server.HTMLEncode(rs.Fields("CustomerID").Value)%>
<BR></FONT></TD>
<TD BORDERCOLOR=#c0c0c0 >
<FONT SIZE=2 FACE="Arial" COLOR=#000000>
<%=Server.HTMLEncode(rs.Fields("CompanyName").Value)%>
<BR></FONT></TD>
<TD BORDERCOLOR=#c0c0c0 >
<FONT SIZE=2 FACE="Arial" COLOR=#000000>
<%=Server.HTMLEncode(rs.Fields("ContactName").Value)%>
<BR></FONT></TD>
<TD BORDERCOLOR=#c0c0c0 >
<FONT SIZE=2 FACE="Arial" COLOR=#000000>
<%=Server.HTMLEncode(rs.Fields("ContactTitle").Value)%>
<BR></FONT></TD>
<TD BORDERCOLOR=#c0c0c0 >
<FONT SIZE=2 FACE="Arial" COLOR=#000000>
<%=Server.HTMLEncode(rs.Fields("Address").Value)%>
<BR></FONT></TD>
<TD BORDERCOLOR=#c0c0c0 >
<FONT SIZE=2 FACE="Arial" COLOR=#000000>
<%=Server.HTMLEncode(rs.Fields("City").Value)%>
<BR></FONT></TD>
<TD BORDERCOLOR=#c0c0c0 >
<FONT SIZE=2 FACE="Arial" COLOR=#000000>
<%=Server.HTMLEncode(rs.Fields("Region").Value)%>
<BR></FONT></TD>
<TD BORDERCOLOR=#c0c0c0 >
<FONT SIZE=2 FACE="Arial" COLOR=#000000>
<%=Server.HTMLEncode(rs.Fields("PostalCode").Value)%>
<BR></FONT></TD>
<TD BORDERCOLOR=#c0c0c0 >
<FONT SIZE=2 FACE="Arial" COLOR=#000000>
<%=Server.HTMLEncode(rs.Fields("Country").Value)%>
<BR></FONT></TD>
<TD BORDERCOLOR=#c0c0c0 >
<FONT SIZE=2 FACE="Arial" COLOR=#000000>
<%=Server.HTMLEncode(rs.Fields("Phone").Value)%>
<BR></FONT></TD>
<TD BORDERCOLOR=#c0c0c0 >
<FONT SIZE=2 FACE="Arial" COLOR=#000000>
<%=Server.HTMLEncode(rs.Fields("Fax").Value)%>
<BR></FONT></TD>
</TR>
<%
rs.MoveNext
loop
%>
</TBODY>
<TFOOT></TFOOT>
</TABLE>
Recall that the main reason for learning about the structure of the ASP file is to make minor adjustments or permit the use of file DSNs. I've already shown where you would edit the ASP script to use a file (instead of a system) DSN. You can also edit the first component to show a different subset of rows and columns from the underlying datasheet. One way to do this is to modify the SQL statement so that it includes or excludes different rows. You can decide to leave the SQL statement alone, but not show selected fields. To block a field from appearing, you must remove it from both the table heading and body in the second and third blocks. You can also show just the first 10 records in a table. Do this by restricting the number of passes through the loop to 10. By extending this logic, you can show any block of records from the recordset.
A parameter query is a fast, easy way to let a user look up information in an Access table. The example in FIGURE 8 shows a query that will return a company's contact person (along with phone and fax numbers) from the Northwind Customers table. The parameter query automatically prompts for a Customer ID.
FIGURE 8: A parameter query to look up customer contact information from the Northwind database.
Notice in FIGURE 8 that the query explicitly sets the parameter data type to text. When publishing a parameter query to the Web, it's essential that you designate the data type for any criterion that is a text field. Because the entry in the Criteria row from the Query-by-Example grid must match perfectly the Parameter column entry in the Query Parameters dialog box, it's efficient to copy and paste the entry in the Criteria row to the Parameter column.
When you publish an Access parameter query with the Publish to the Web Wizard, it creates two files. One of these is an HTML file that accepts the criterion for which a user wants to search. This file mimics the automatic pop-up form that a parameter query displays in Access. The second file displays a table with the return set matching the criterion. This is an ASP file. The HTML file contains a simple HTML form that calls the ASP file.
Aside from these differences, you publish a parameter query in a nearly identical way to a datasheet. Select the parameter query on the Publish to the Web Wizard's second screen, choose Dynamic ASP format on the fourth screen, and designate a system DSN on the fifth screen, if you are using one. The folder in which you choose to save your files on the sixth screen will hold both the HTML and ASP files for the parameter query. This is not optimal; the ASP and HTML files work best in folders with different permissions. Any ASP file requires Execute Scripts permission. In addition, you will typically want to disallow Read permission, because it can expose your scripts. Any HTML file requires Read permission, because that is the only way a browser can view it. Therefore, if you store a parameter query's HTML file in the same folder as its ASP file, you must assign that folder Read permission so that a visitor can see the parameter query's prompt. An alternative is to place the HTML and ASP files in separate folders — one with Read permission and the other with Execute Scripts permission.
If you elect to store a parameter query's HTML and ASP files in separate folders, you will need to edit the code for the form in the HTML file. The two files for the parameter query in FIGURE 8 have the names qprFindCustomer_1.html and qprFindCustomer_1.asp. FIGURE 9 shows the initial HTML code for the form in qprFindCustomer_1.html. Notice that its Action argument points at an ASP file in the same folder. When you move the HTML file to a different folder, you will need to revise the ACTION argument so that it includes a path to the ASP file. In my example, the HTML appears in the root virtual directory of the cabxp5 Web server, and the ASP file resides in a virtual directory named myasps. Each virtual directory corresponds to a folder. Changing the ACTION argument to the following allows it to reference the ASP file:
ACTION="../myasps/qprFindCustomer_1.ASP"
Figure 10 shows the two parameter-query screens in action. These correspond to the Access parameter query for the Northwind database that appears in FIGURE 8. The top panel in Figure 10 shows the form. A user inputs a Customer ID — BOTTM, in this case — into the text box on the form. Clicking the Run Query button launches the parameter query. As you can see from the code in FIGURE 9, this button is nothing more than an HTML Submit button. Notice from the Address list box that the form appears in the root virtual directory of the cabxp5 Web server http://cabxp5/qprFindCustomer_1.html. This file calls the ASP file in the myasps virtual directory of the cabxp5 server.
FIGURE 9: The HTML code for the published parameter query in FIGURE 8.
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type"
CONTENT="text/html;charset=windows-1252">
<TITLE>qprFindCustomer</TITLE>
<BODY>
<FORM METHOD="GET" ACTION="qprFindCustomer_1.ASP">
[Customer ID: ] <INPUT TYPE="Text"
NAME="[Customer ID: ]"><P>
<INPUT TYPE="Submit" VALUE="Run Query">
</FORM>
</BODY>
</HTML>
Figure 10: The published parameter query in FIGURE 8, in a browser.
The bottom panel in Figure 10 displays the return set from the parameter query. It shows contact information for the customer with a Customer ID of BOTTM. The address box shows that the browser presents the result of the script in qprFindCustomer_1.asp. This file resides in the myasps folder. The arguments after the question mark indicate the HTML file user input that calls the ASP file. The GET method in FIGURE 9 forces the argument into the URL.
There is at least one more significant parameter-query issue. Microsoft acknowledges a bug with how the Publish to the Web Wizard translates any criterion that includes Like. The simplest solution is not to support Like in your parameter queries. If that is unacceptable, then follow the edit instructions that Microsoft gives for correcting the SQL syntax in the wizard-generated ASP file. These instructions appear in Microsoft Knowledge Base report Q162977 (http://support.microsoft.com/support/kb/articles/Q162/9/77.asp).
Publish Dynamically with ASP (or Perish)
The Publish to the Web Wizard and ASP dynamic publishing represent a powerful way for Access developers to significantly extend the reach of their applications. VBA developers can easily reach remote communities of users that extend far beyond their LAN, by dynamically publishing datasheets and parameter queries. This can substantially increase the worth of Access database contents and VBA developer skills.
VBA developers who take advantage of this opportunity will have to learn some new techniques. It is essential that you become familiar with DSNs. You should also appreciate the difference between system and file DSNs. If you wish to take advantage of the special benefits of file DSNs, then you must learn to modify ASP script files.
VBA developers will also benefit from becoming familiar with the basics of ASP scripting. This article segments an ASP file for a dynamically published datasheet into three distinct parts. By dividing the whole into relatively distinct components, it is easier to learn the roles of each. Identifying the components of an ASP file also clarifies how to go about editing them so they can serve your special needs. The article further clarifies the topic through its treatment of parameter queries. It illustrates why and how to edit parameter-query files so they work optimally when you publish them on a Web server. My suggestion can rescue your parameter queries from not working, and protect the script behind the query (which can enhance the security of your site).
Finally, this article illustrates two critical applications for the Publish to the Web Wizard. Dynamically published datasheets will show the most current database revisions. Parameter queries allow site visitors to dynamically query an Access database — with a browser. Together these two applications can make Access databases serve larger pools of users than ever before.
Rick Dobson, Ph.D. heads his own database and Web development consultancy. His byline appears in several leading publications, including Byte, and he is a Contributing Editor to Microsoft Interactive Developer, a Microsoft publication. In addition, Rick is an MCT who is certified to teach Mastering Microsoft Office 97 Development. You can reach him at RickD@cabinc.win.net.