You have numerous options to customize a page generated by the File-Export
command. There's so much repetition in HTML code that it's often wise to use an
auto-generated page as a starting point. As a database programmer who is just
starting with Web development or who doesn't require the Web for most
applications, you will likely want to spend more of your time adapting
VBScript.
One way to use VBScript is to specify a custom connection string that does
not depend on a DSN. This frees you from having to rely on the graphical
technique described earlier for specifying a connection to your database file. Even if you like graphical approaches, there will be times when the
graphical approach isn't readily available—for example, when working with a
remote Web site.
Wouldn't it be great if you could tap your knowledge of writing
The sample we'll look at momentarily has several sections and illustrates
some secondary issues I have not mentioned yet. The first section shows three
approaches to developing a connection string. The next section uses the
connection string as one of the arguments for the
recordset Open method. After that, the sample repeats the same basic
flow as the code auto-generated from the File-Export command you saw. However,
it substitutes a more familiar reference name, rst1, for the Recordset
object. If you like to name your objects after their sources,
you mightreplace rst1 with rstShippers. However, this is
strictly arbitrary. The point is that you aren't locked into the reference
names that the File-Export command produces.
A connection string argument for a Jet database file can contains as few as
two elements. One element names the provider. The second denotes the path and
file for the Access database file. The sample uses the variable filepath
to designate the second element.
The specification for the filepath variable dictates that the three
approaches for specifying the connection string differ. The first approach uses
the MapPath method of the ASP Server object to reference the
drive and root directory of the server. The expression in the first approach
appends a string to this return value with the path within a Web site on the
database file's server. The database file is fpnwind.mdb, which is a sample
file that ships with FrontPage 2002. The pma10 Web site's root folder is pma10,
and the fpnwind.mdb file resides in a subfolder named fpdb. The cnn1.Open
statement shows the syntax for concatenating the filepath argument to
the end of the connection string for cnn1.
The second and third approaches to developing a connection string begin with
comment markers. Both approaches demonstrate interesting syntax variations that
you might find useful in some situations. When the database file is in the root
folder of a Web site, as in the second approach, you can simplify the
expression for the filepath string by including the database filename in
quotes as the argument for the MapPath method. In this case, the
database name references a database with a single table—the Shippers
table. The third approach gives an example of the syntax for specifying the
path to a folder that isn't necessarily located at the Web site. The path leads
to the database file for this chapter. The file resides in a folder outside the
\inetpub directory for the Web server but on the same computer as the Web
server.
NOTE
Attempting to reference a file on a remote computer can
generate an error when working with Jet database files and ASP.
After specifying the connection, the procedure writes a diagnostic message
to the page that the server returns to the browser. This message identifies the
drive, path, and filename for the Access database file to which the page
connects. The message appears on two lines. One line is ordinary text
explaining the meaning of the second line. This second line is the value of the
filepath variable. Because your code specifies this variable's value in
VBScript, you can use the <%= and %> delimiters to include this value on
the page. Just before the two lines specifying the source for the table, the
listing shows the syntax for designating a comment. Although this line does not
appear on the Web page, you can view it from the listing. By moving the three
trailing characters (->) to the end of the second line, you can make the
message about the page's source invisible but retain the code for subsequent
use.
The next block of code shows the syntax for specifying a recordset for the
page. All three potential data sources include a Shippers table, and the Open statement simplydesignates this
table name as its source. Also, notice that the code uses intrinsic constants.
ASP does not natively define these constants. You can use an ASP #include
directive to reference a file with the constants, or you can just define some
constants and use them in your code. The sample demonstrates the latter
approach.
The remainder of the procedure is a direct copy of the code auto-generated
by the File-Export command, with one exception. It uses a new name for the
recordset reference. Obviously, if you change the recordset reference name when
instantiating the recordset, your code needs to use that name when writing rows
of data to the HTML table for the browser. Developers switching to ASP code
must keep such details in mind as they begin their migration.
<HTML>