Home > Articles > Computer Software > Business Office Software > Database Software > Other

  • Print
  • + Share This
  • 💬 Discuss
This chapter is from the book

Saving a Form As a Data Access Page

Access 2002's Data Access Pages (DAP) feature has undergone a major facelift in its second 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 "Saving Forms As DAP," p. 1121.

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 2002's new 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 3.41). Click OK to open the New Data Access Page dialog.

    Figure 3.41 Access 2002's Save As dialog adds the capability to 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 3.42).

    Figure 3.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 3.43).

    Figure 3.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.x, close the page, choose File, Web Page Preview. Figure 3.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 XP installed can simultaneously edit existing contacts, add new contact records, or delete obsolete contacts with this page.

    NOTE

    To prevent conflicts with the preceding steps, the page shown in Figure 3.43 is saved as Contacts2.htm in the \Seua10\Chaptr03 folder of the accompanying CD-ROM.

    Figure 3.44 Choosing File, Web Page Preview displays the redesigned Contacts.htm page in IE 5.x. In this example, the page was saved in the ...\Office10\Samples folder.

  6. To view the XML, Dynamic HTML, 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. Figure 3.45 shows the Script Editor displaying a fraction of the script required to generate DAP.

    Figure 3.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 3.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.

  • + Share This
  • 🔖 Save To Your Account

Discussions

comments powered by Disqus