Chapter 11
Publishing Radioactive Forms

In This Chapter

• Publishing Access forms to the Access wizard
• Linking to the published forms
• Publishing forms with embedded subforms
• Understanding which parts of the form are actually published

The real advantage to using the Access Publish to the Web Wizard to publish to the Active Server Pages (ASP) format is apparent when you publish forms. When you publish a form using the ASP format, the wizard generates an ASP page that looks and acts like an Access form. You can use the ASP page to view and update records in the Access database.

This chapter explores the publishing of Access forms to the ASP format and takes a look at the pluses and minuses of the Access-generated ASP pages.

Publishing an Access Form

Publishing an Access form to the ASP format is very similar to publishing a table or query to the ASP format, which I cover in Chapter 10.

Before you start publishing your Access forms to the ASP format, you need to have a few things in place:

• You must be using a Microsoft Web server with Active Server Pages installed.
• You must have a Web directory setup to hold your ASP files. Assign both Read and Script access rights (or Read and Execute rights for earlier versions of Microsoft Web servers) to this Web directory by using the Internet Service Manager program.

Chapter 2 has more details on obtaining and configuring Microsoft Web servers and creating Web directories. I also discuss configuring your Web server for Active Server Pages in Chapter 10.

Following is a brief look at how to publish a form:

1. Open an Access database, start the Access Publish to the Web Wizard, and click Next until you reach the fourth wizard page.
2. Select the form or forms you want to publish on the second wizard page.
3. Select the Dynamic ASP (Microsoft Active Server Pages) publishing option on the fourth wizard page, as shown in Figure 11-1, and click Next.
4. On the fifth page, type the data source name and other optional fields.

   If the form you're publishing contains a subform, tab to the Server URL text box. Type the URL address of the virtual Web directory where the ASP files will be hosted. This address points to the virtual Web directory where you store the files, not the actual files (see Figure 11-2).

   For example, if your Web server is accessible across an intranet, then type an address using the following syntax:

   http://server_name/virtual_directory/

   If you connect to the Web server across the Internet, then enter an address using the following syntax:

   http://www.site_name/virtual_directory/

   If the form doesn't contain a subform, you can leave the Server URL text box blank (see Figure 11-3). Entering an address doesn't do any harm, but getting an address wrong is easy. You may as well leave the text box blank. In addition, if you decide later to move the files to a different Web directory, the form won't work if you've entered a server URL here.

5. Click Finish to generate the pages and quit the wizard.

   Enter whatever you want on the remaining wizard pages before clicking Finish.

The Published ASP Files

When you use the Publish to the Web Wizard to publish an Access form, you end up with at least two files -- perhaps three, if you publish a form with an embedded subform. The files generated by the wizard are

• form_1.asp: This is the main ASP file, the one you link to. The file grabs the data displayed on the form and inserts an HTML Layout control into the Web page.
• form_1alx.asp: This ASP file creates the form displayed by the HTML Layout control.
• subform.asp: This file is created by the wizard only if the published Access form contains a subform. If so, then this file is responsible for grabbing the data for the subform and displaying it in the HTML Layout control.

For example, if you publish a form (with no subform) named frmMenuItems, the wizard generates the following files:

frmMenuItems_1.asp 


 frmMenuItems_1alx.asp

If you publish a form named frmOrders that contains an embedded subform named frmOrderItemsSub, you get the following files:

frmOrders_1.asp 


 frmOrders_1alx.asp 


 frmOrderItemsSub.asp

Post-Wizard Housekeeping

Before you can use your ASP files, you must perform three additional steps. These steps are identical to what you need to do when publishing a table or query to the ASP format:

1. Copy the ASP files to the server.
2. Copy or move the Access database to the server.
3. Create an ODBC System data source to link the ASP page to the database.

Chapter 10 gives you all the details on these steps.

Previewing the Results

To view the wizard-published forms, you need to link to the main ASP page. But first, there's a catch.

The ASP files that the Access wizard generates differ in one important way from all the other Web pages that the wizard generates: You can view the ASP files only by using Microsoft Internet Explorer (IE) 3.0 or later. You need Internet Explorer because the wizard-generated ASP files send VBScript code that uses the HTML Layout control to the Web client.

The wizard uses the HTML Layout control to allow precise two-dimensional positioning of items on the page. This control runs only in browsers that support ActiveX controls, which, for now at least, means that you can view the wizard-published forms by using only Internet Explorer Version 3.0 or later.

As is the case in Chapter 10, the exact URL you link to varies, depending on if the Web server is on an intranet or the Internet.

If your Web server is accessible across an intranet, then you link to the ASP page using the following syntax:

http://server_name/virtual_directory/form_1.asp

where server_name is the machine name of the Web server, virtual_directory is the Web folder that hosts the Web page, and form_1.asp is the name of the ASP page generated by the Access wizard.

For example, if your server name is catfish and the published ASP file is frmEmployees_1.asp and located in the Web_Meals directory, you enter the following URL:

http://catfish/Web_Meals/frmEmployees_1.asp

If you connect to the Web server across the Internet, then you link to the ASP page using the following syntax:

http://www.site_name/virtual_directory/form_1.asp

where site_name is the domain name of the Web server, virtual_directory is the virtual Web directory that hosts the Web page, and form_1.asp is the name of the ASP page generated by the Access wizard.

For example, if your site name is web_meals.com, and the published ASP file is frmEmployees_1.asp and located in the root directory of the Web server, you enter the following URL:

http://www.web_meals.com/frmEmployees_1.asp

When you link to the wizard-generated ASP page using Internet Explorer, the ASP query executes on the server and the ASP engine generates a Web page consisting of a mixture of HTML and VBScript on the fly and returns the page to the browser. Because the Web page contains VBScript and references to the HTML Layout control, you need to use a Microsoft browser, as shown in Figure 11-4.

If you compare the ASP version of the form with the original Access form (shown in Figure 11-5), you can see that the wizard does an admirable job in converting the Access form into the Web equivalent.

If you attempt to view the page in a browser that doesn't support ActiveX controls and VBScript, you get a page that looks similar to the one shown in Figure 11-6.

Publishing a Form with an Embedded Subform

The trick to publishing a form with a subform successfully is to get the Server URL address on page 5 of the wizard correct. See Figure 11-2 and the discussion in the section "Publishing an Access Form" for more details.

The wizard publishes subforms only in datasheet view and only as read-only HTML tables. To function properly, the published subform must link to the main form using the LinkChildFields and LinkMasterFields properties of the subform control, not custom VBA code. In addition, the wizard doesn't support nested subforms.

For example, the Meals.mdb database contains a form, frmOrders, with an embedded subform (frmOrderItemsSub). The Access version of this form appears in Figure 11-7.

The Access Publish to the Web Wizard does a good job converting the frmOrders form to an ASP form, as shown in Figure 11-8. As with all published subforms, the subform itself becomes read-only when converted to the ASP format.

Using the Published Forms

The ASP version of your Access form attempts to mimic the look and behavior of the Access form it's based on. However, a few differences crop up in how the ASP version of the form works:

• Navigating around: Click the navigational buttons at the bottom left of the form to move from one record to another. The buttons behave the same as their Access 97 counterparts. When you navigate to a different record, notice that the entire page is refreshed and repainted. On slower machines, or machines connected to the server over a slow dialup line, the refresh delay is quite noticeable.
• Using combo box and list box controls: You can use combo controls just as you use them in Access, even when the controls are bound to a lookup table. (See the Customer and Employee fields in Figure 11-8.) Any code linked to events of the controls, however, doesn't work.

  Bound list box controls do not behave correctly. When browsing a saved record, the list box doesn't highlight the correct value.

• Updating records: To update a record, directly edit the values in the controls on the form just as you do in the Access version of the form. Unlike in Access, however, you must also click the Commit button or else you lose your changes. After you commit the changes, the form repositions to the first record in the recordset.
• Deleting records: Click the Delete button while a record is displayed, and you end up deleting the record from the database after a confirming dialog box appears. After you delete the record, the form repositions to the previous record in the recordset.
• Refreshing records: If you want the currently displayed record to refresh with any changes made by other users since you began viewing the record, click the Refresh button.

Publishing Better Forms

The code behind the Access Publish to the Web Wizard does some amazing things. A sophisticated algorithm analyzes the Access form and spits out ASP code to simulate the look and feel of the Access form. The wizard hardly does a perfect job, however, and in fact has problems converting certain form elements.

What's published and what's not?

Forms in Access can be quite a bit more complex than tables or queries. As you may guess, the Access Publish to the Web Wizard can't convert everything on a form to a Web page. Table 11-1 summarizes which parts are published and which parts aren't.

As you can see from Table 11-1, the wizard doesn't publish many parts of a form, including VBA code, macros, images, lines, rectangles, and expressions.

Form-publishing tips

To minimize your headaches when publishing forms, consider the following tips and tricks:

• Keep it simple. The simpler a form is, the better it looks when published.
• Make your forms small. The browser version of the form is usually larger, so the smaller you make your forms, the more likely they will fit within one browser page.
• If you have controls too close to the left edge of the form, the wizard may chop off the labels, as shown in Figure 11-9. Whether or not the wizard wields a hatchet depends on how close your labels are to the left-hand margin, if you're using a template, and the width of the form. If the labels get cut off, open the Access form in design view, move the labels to the right a bit or reduce the width of the form, and republish the form.
• By default, the background color of the published form is gray regardless of the color of the original Access form. If you want to change the background color, open the alx ASP file in Notepad, and search for the first instance of <DIV>. This tag should look something like the following:

      <DIV ID="
frmEmployees_1alx" 


        STYLE="LAYOUT:FIXED;HEIGHT:
222;WIDTH:
528;">

      <DIV BACKGROUND="
#fce503" ID="
frmEmployees_1alx" 


        STYLE="LAYOUT:FIXED;HEIGHT:
222;WIDTH:
528;">

• If you move a wizard-generated form to another Web directory and you have hard-coded the Server URL into the ASP files (this is necessary if the form contains an embedded subform), you can do one of two things:
  • Republish the form with the new URL address.
  • Search and replace the URL in both the form_1.asp and form_1alx.asp files and replace each http: address with the new address.
• If you don't have the HTML Layout control installed on your system and you attempt to view a published Access form, then code attached to the published form attempts to download the control from www.microsoft.com and install the control onto your system. This process may take several minutes, so be patient. The download may fail, however, for a variety of reasons, including:
  • Internet Explorer can't download the control because you aren't hooked up to the Internet or you're connected through a firewall. You may be able to circumvent this problem by obtaining a later version of Internet Explorer. IE 3.01 and later versions include the HTML Layout control automatically.
  • The security of your Internet Explorer (choose View-->Options, and click the Security tab) is set to the High setting. Change this value to the Medium setting.
  • If you're using IE 3.0, make sure that you select each of the Active Content settings on the Security tab of the Options dialog box.

How Wizard-Generated Pages Stack Up Against the Alternatives

The Access Publish to the Web Wizard makes it easy to publish Access forms to ASP pages that you can use to view and update the records. The pages that the wizard produces, however, have several shortcomings.

• You must use a Microsoft Web Server with ASP support installed.
• Your Web browser must be Internet Explorer.
• You must have the HTML Layout control installed on your machine.
• The Web pages are slow and lack any navigational aids beyond the first record, next record, previous record, last record, and new record buttons.

Alternatives to the Access-generated pages are not without shortcomings of their own:

• Static HTML doesn't have any of these shortcomings, but you also can't use static HTML to link to or update data stored in a database.
• IDC Web pages also must run on a Microsoft Web server, but they are browser-independent. To create the equivalent forms, however, you have to hand-code a lot of IDC and HTX files.

In the next part of this book, you explore another alternative: Microsoft Visual InterDev. You use this powerful tool to produce ASP pages that share many of the strengths of the Access Publish to the Web Wizard-generated pages, while not sharing many of its shortcomings.