Saving a Form as a Data Access Page

Access 2003's data access pages (DAP) feature underwent a major facelift in its second Access 2002 incarnation. One of the most useful additions to DAP is the capability to save a conventional Access form as a Web page. There are serious limitations to the design of forms that you can convert automatically to DAP. Some of the restrictions are due to the limited repertoire of HTML control objects; others relate to problems with forms that depend on a value in another form to supply data. The advantages of DAP as a means of quickly deploying a simple multiuser Jet application on your intranet often outweigh the form design limitations.

For a list of the most important limitations in form design for DAP, see "Understanding the Limitations of the DAP Conversion Process," p. 1066.

Simple forms, such as the Contacts form of Contacts.mdb, convert to DAP satisfactorily, but even they usually require a few design tweaks to optimize their design for the Web. To give Access 2003's Save as DAP function a test run with the Contacts form, follow these steps:

1. Open Contacts.mdb, and click the Enter/View Contacts button of the Main Switchboard to open the Contacts form.

2. Choose File, Save As to open the Save As dialog. Open the As list, and select Data Access Page (see Figure 2.41). Click OK to open the New Data Access Page dialog.

   Figure 2.41. Access 2003's Save As dialog can save a table, query, form, or report as a Data Access Page.

   

3. Accept the default page name, Contacts.htm in the My Documents folder, and click OK to convert the form. When conversion completes, the Contacts page is behind the Contacts and Main Switchboard forms. Click the Contacts page to bring it to the foreground (see Figure 2.42).

   Figure 2.42. The top of the Contacts page appears here in DAP Page view. Data access pages don't support the Page Break control, so there's extra vertical spacing between the controls on the form's pages 1 and 2.

   

4. Scroll to the bottom of the page to expose the Data Source Control (DSC), a member of the Office Web Components (OWC) that DAP use for record navigation (see Figure 2.43).

   Figure 2.43. The bottom of the Contacts.htm page also has extra space between the page 2 controls and the DSC.

   

   Note

   The four command buttons of the original Contacts form appear below the DSC but they don't function. DAP require VBScript or ECMAScript (JavaScript/JScript) event-handling code, but they don't support VBA code.

5. To open the Contacts.htm page in Internet Explorer (IE) 5+, right-click the page's title bar and choose Web Page Preview. Figure 2.44 shows the page after modifying its design to conserve browser space and eliminate nonfunctioning buttons. After you deploy the page to your Web server, multiple users with Office 2003 installed can simultaneously edit existing contacts, add new contact records, or delete obsolete contacts with this page.

   Figure 2.44. Choosing Web Page Preview displays the redesigned Contacts.htm page in IE 6+.

   

   Note

   

   To prevent conflicts with the preceding steps, the page shown in Figure 2.43 is saved as Contacts2.htm in the \Seua11\Chaptr02 folder of the accompanying CD-ROM. If you installed the sample files in the default location, Contacts2.htm is in your C:\Program Files\Seua11\Chaptr02 folder.

6. To view the XML, Dynamic HTML (DHTML), and Cascading Style Sheets (CSS) code needed to create typical DAP, close IE 5+, return to the Contacts.htm page, change to Design view, and click the Microsoft Script Editor button on the toolbar. Alternatively, right-click the title bar and choose Microsoft Script Editor. Figure 2.45 shows the Script Editor displaying a fraction of the script required to generate DAP.

   Figure 2.45. The Microsoft Script Editor for DAP corresponds to the Office VBA editor for VBA code in Access modules.

   

7. Scroll to the bottom of the window to view the nonfunctional VBA code that the Save as DAP process adds to the page for reference. Close the editor to return to Access, and return Contacts to Page view.

It's clear from a cursory inspection of the code shown in Figure 2.45 that writing VBScript to handle page- and control-level events isn't for the faint of heart. Fortunately, VBScript is a subset of VBA; if you gain a solid foundation in writing VBA functions and procedures, adapting to VBScript doesn't require a major effort.