View Active Server Page Source

INTERNET • INTRANET • NETWORKS • PROGRAMMING

View ASP Code (/bret/resume/adotutorial/default.asp)
Go Back to

<%@ LANGUAGE="VBSCRIPT" %>

<%
 'Keep on truckin....
 On Error Resume Next
 Session("HITS") = Session("HITS") & Now() & " - " & Request.ServerVariables("SCRIPT_NAME") & vbCrLf
%>

<html>
<head>
<meta NAME="GENERATOR" Content="Microsoft Visual InterDev 1.0">
<meta HTTP-EQUIV="Content-Type" content="text/html; charset=iso-8859-1">
<title>Net Connex Data Connectivity Tutorial</title>
</head>
<a NAME="TOP"></a>
<%
 'Dim some local variables
 Dim conDB 'The variable for the connection object
 Dim conMain 'The variable for the command object
 Dim rsData 'The variable for the recordset object

 'Assign session level objects to local variables
 Set conDB = Session("CON") 'Connection object
 Set cmdMain = Session("CMD") 'Command Object
 Set rsData = Session("DATA") 'Recordset Object
%>







<center>
Net Connex ADO/ASP Database Connectivity Primer
</center>




A web site just isn't a web site these days unless it is dynamic, data driven, and user focused.
We expect the web sites we visit, and develop, to always be current, the data to be fresh and
accurate, and we want the ability to ask for specific information. Active Server Pages, and ADO
are two Microsoft technologies that provide developers with the tools to meet those demands head
on, and to do so in an easy yet scalable way.

Active Server Pages (ASP) is Microsoft's offering for server side scripting in a web environment.
ASP makes it possible to provide dynamic, user driven web sites. Web sites can show users a
completely different set of content every time the user refreshes a page. Results can be
formatted to meet the capabilities of the web browser. Two of the big three requirements of
web sites can be met with ASP alone. The data driven demand though is left unanswered by ASP
itself. ASP instead relies on other solutions to gain access to data.

Developers, of any kind, are really in the business of manipulating data. All applications
eventually end up accepting, analyzing or archiving data. This global need for data
has led to innumerable approaches to provide access to databases. Microsoft's latest solution
for a universal means of accessing data is OLEDB. OLEDB gives developers an open,
powerful set of tools to both provide as well as consume data of virtually any kind. OLEDB by
itself though can be cumbersome or impossible to work with from higher-level languages such as
Visual Basic, or VBScript. Microsoft therefore provides us with ADO (Active Data Objects) as a
wrapper object model to provide access to OLEDB from those languages.

This document serves as a primer for developers that are interested in using ADO to gain
access to databases from Active Server Pages. It assumes your familiarity with ASP, VBScript,
and general database terminology. If this is not the case, you might be better served if
you reviewed the documentation on those topics available in the MSDN library. You can
gain access to this information via the web at <a href="http://msdn.microsoft.com/">http://msdn.microsoft.com/</a>



<a NAME="THEPLAN"></a>

The Plan: <a HREF="default.asp#top">top</a>

This tutorial covers the code that you would need to put into the global.asa file
of an ASP application, as well as the code to use in individual pages to access
a database. The samples deal with an Access database, but the concepts are identical no
matter what type of database you are accessing.

To start, there will be a brief (very brief) overview of the ADO object model, then
the major ADO objects will be discussed

Once the use of the ADO objects have been outlined, there is an <a HREF="default.asp#TOGETHER">actual sample of pulling data
from a database</a>. As an added feature, you can view all of the ASP code for this tutorial. There are
<a HREF="default.asp#VIEWSOURCE">links to the code pages at the bottom of this page</a>. Finally, to top it all off, there
is another <a href="customquery.asp">sample page</a> that allows you to enter your own query to run against the database.
The <a href="customquery.asp">customquery.asp</a> page takes the concepts outlined in this document and puts them to
good use. It will give you a more compact example to reference when you are trying to figure out this ASP stuff.

The sample database is a collection of flashcard information. This is an actual database of real questions and resources
that I created while studying for various tests. There are two tables in the database. The first is the FlashCards table
with the individual cards in them. The second table is the Resources table. It has the bibliographic
information stored in it. The FlashCards table has a foreign key relationship to the Resources
table on the ResourceID column.

Now that you've got the lay of the land, let's get started.



<a NAME="ADOMODEL"></a>

The ADO Object Model: <a HREF="default.asp#top">top</a>

ADO provides three basic objects to control your access to databases. You do
not need to create objects of all three types, you can create them independently. For example,
you never NEED to specifically create a Connection object or a Command object to open a recordset.
However, if you take the time to understand ADO's structure, and implement the
objects as they are intended, you arrive at a more structured solution, as well as
bypass some pitfalls to declaring all objects outside of the hierarchy.

When dealing with an ASP application you have various levels that you can
scope your database objects at. The Application level, the session level,
or the page level. Objects and variables stored at the application level are visible to
all visitors to an ASP web site. Objects and variables stored at the session level are
visible only to the current session (visitor). Finally objects stored at the page level visible
only to the current page. Where it makes sense I like to store my objects
at the session level. This gives all of your pages access to the same
data resources, provides an easy way to keep your place in recordsets
between pages, and finally provides some performance increase because you
do not need to re-query the data every time you load a page.

It is also important to note that there are many ways to use the objects in
conjunction with each other that are not outlined in this document. The Connection's Execute method
provides another convenient means to create recordsets, or execute update queries. This tutorial is
only an overview, and describes one method to retrieve data from a database into an HTML page. It is
up to the reader to research the other features and functions of ASP and ADO to exploit all of their capabilities.

<center>
<table WIDTH="1" BORDER="1" BORDERCOLOR="#000000" CELLPADDING="5" CELLSPACING="0">
 <tr>
 <th BGCOLOR="C0C0C0" ALIGN="CENTER">The ADO Object Model</th>
 </tr>
 <tr>
 <td NOWRAP>
 <a HREF="default.asp#CONNECTION"><img SRC="./images/objconn.gif" WIDTH="83" HEIGHT="20"></a> 
 <img SRC="./images/parmult.gif" WIDTH="15" HEIGHT="26"><img SRC="./images/colerror.gif" WIDTH="83" HEIGHT="20"><img SRC="./images/paracros.gif" WIDTH="15" HEIGHT="26"><img SRC="./images/objerror.gif" WIDTH="83" HEIGHT="20"> 
 <img SRC="./images/parmult.gif" WIDTH="15" HEIGHT="26"><a HREF="default.asp#COMMAND"><img SRC="./images/objcomma.gif" WIDTH="83" HEIGHT="20"></a> 
 <img SRC="./images/parlower.gif" WIDTH="15" HEIGHT="26"><img SRC="./images/parchild.gif" WIDTH="15" HEIGHT="26"><img SRC="./images/colparam.gif" WIDTH="83" HEIGHT="20"><img SRC="./images/paracros.gif" WIDTH="15" HEIGHT="26"><img SRC="./images/objparam.gif" WIDTH="83" HEIGHT="20"> 
 <img SRC="./images/parchild.gif" WIDTH="15" HEIGHT="26"><a HREF="default.asp#RECORDSET"><img SRC="./images/objrecor.gif" WIDTH="83" HEIGHT="20"></a> 
 <img SRC="./images/parblank.gif" WIDTH="15" HEIGHT="26"><img SRC="./images/parchild.gif" WIDTH="15" HEIGHT="26"><img SRC="./images/colfield.gif" WIDTH="83" HEIGHT="20"><img SRC="./images/paracros.gif" WIDTH="15" HEIGHT="26"><img SRC="./images/objfield.gif" WIDTH="83" HEIGHT="20"> 
 </td>
 </tr>
</table>
</center>



<a NAME="CONNECTION"></a>

The Connection Object: <a HREF="default.asp#top">top</a>

The code in this tutorial will use the three main objects in ADO. The Connection object,
the Command object, and the Recordset object. I will start by defining an ADO 'Connection'
object. The connection object represents a connection between your ASP application, and the database.
Again, this can be created at the application, session, or page level. To define a connection at
the session level, we use the global.asa file in the ASP applications root directory.

A connection object basically tells your ASP code where the database is, how to connect to
it, and provides a means of actually initiating that connection. The advantages to specifically
creating a connection object are many. The basic benefits are that it provides a structured means to
connect to your database, a way to persist that connection throughout the lifetime of a session, and
finally it allows gives some performance increase by reducing the number of subsequent connections that
must be made to the database.

One other capability of connections that is not covered in this tutorial is 'Connection Pooling'.
Connection Pooling is a feature of the database provider that will keep discarded connections open for a
specified amount of time. If a new connection request is made before the idle connection object is destroyed
and it is for the same database with the same username and password, the idle connection object will be used. This
saves the time and overhead of re-connecting to the database, etc. Your database provider may not support
connection pooling. Review the documentation for your database provider to find out about connection pooling and how
to configure it.

The code to create, and persist the connection at the session level is put into the
Session_OnStart event handler in the global.asa file. When a user first visits the web site (or ASP application)
a Session object is started for them. When the session object is first started, the 'OnStart' even will be fired
and the code in the 'Session_OnStart' event handler in the global.asa file will be executed. Remember, this is only done
when the session is first created. Sessions remain active on the server as long as the user continues to load pages from
within the same web site (or ASP application). If the user leaves the site, and the session will remain active until it
exceeds the timeout limit. The default timeout is 20 minutes, but that can be modified with the Session.Timeout property.

The code to create our connection object looks like this:

<center>
<table WIDTH="90%" BORDER="1" CELLPADDING="2" CELLSPACING="0" BORDERCOLOR="#FFFFFF">
 <tr>
 <td VALIGN="TOP" NOWRAP BGCOLOR="#F0F0F0">
 Dim conDB
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Dim the variable to hold the connection object
 
 </td>
 </tr>
 <tr>
 <td VALIGN="TOP" NOWRAP BGCOLOR="#F0F0F0">
 Set conDB = Server.CreateObject("ADODB.Connection")
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Create the connection object from the ADODB library
 
 </td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 conDB.Open "Driver={Microsoft Access Driver (*.mdb)};DBQ=D:\216.247.161.1\flash\flash.mdb;"
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Opens the connection using a DSN-less connection string that points to the access database.
 
 </td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 Set Session("CON") = conDB
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Set the session level variable "CON" equal to the connection object. This will persist the
 connection for the duration of the session, or until it is removed programmatically.
 
 </td>
 </tr>
</table>
</center>
 
<center><a href="code.asp?source=/bret/resume/adotutorial/copyofglobal.asa">View the actual global.asa file for this site</a></center>

For the above code segment, remember again that it is in the global.asa file, in the
Session_OnStart subroutine.

You could open the connection object with a System DSN rather than an explicit connection string if you wanted to. This does require the ability to
create DSNs on the server. Also note, that it must be a system DSN that you create. To use a DSN rather than an explicit connection string, the
code to open the connection would look more like this:

<center>
<table WIDTH="90%" BORDER="1" CELLPADDING="2" CELLSPACING="0" BORDERCOLOR="#FFFFFF">
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 conDB.Open "MySystemDSN"
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Opens the connection using a System DSN.
 
 </td>
 </tr>
</table>
</center>

That looks much easier than the first method. Remember though, to open connections to your
databases in this manner requires that you have access to the ODBC configuration utilities
on the server.

Now that our connection object has been created, lets look at the properties for it.
The table below shows the actual properties for the Session("CON") object in this tutorial's
ASP application. Remember, all we specified was the connection string. All of the rest of theses attributes are
set to their default values:

<center>
<table WIDTH="90%" BORDER="1" CELLPADDING="2" CELLSPACING="0" BORDERCOLOR="#FFFFFF">
 <tr>
 <th COLSPAN="2" BGCOLOR="#C0C0C0">Session("CON") Properties</th>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">Attributes</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=conDB.Attributes%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">CommandTimeout</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=conDB.CommandTimeout%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">ConnectionString</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=conDB.ConnectionString%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">ConnectionTimeout</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=conDB.ConnectionTimeout%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">DefaultDatabase</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=conDB.DefaultDatabase%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">IsolationLevel</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=conDB.IsolationLevel%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">Mode</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=conDB.Mode%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">Provider</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=conDB.Provider%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">Version</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=conDB.Version%></td>
 </tr>
</table>
</center>




<a NAME="COMMAND"></a>

The Command Object: <a HREF="default.asp#top">top</a>

You may decide that a command object is a little unnecessary. It does, however, provide you with a couple of
benefits over opening recordsets directly. When using the command object, you can request that the
provider 'prepare' or compile the query if the provider supports it. One other advantage to using
the command object is that you can override the Connection object's CommandTimeout property. If you know
that a particular query will take a long time you can specify a longer CommandTimeout property for the
command object than is set for the connection object. This gives you some control over slow queries.

The command object basically gives you a way to pre-define a query, and the attributes for it. There is
another feature of the Command object that we do not cover here, the Parameters collection. If the command
object will be calling a stored procedure that requires parameters, or a parameterized query, you can set the
parameters by creating parameter objects and adding them to the parameters collection of the command object. It
is up to the reader to research parameters and their use.

The code to create, and persist the command at the session level is put into the
Session_OnStart event handler in the global.asa file. The code to create our command
object looks like this:

<center>
<table WIDTH="90%" BORDER="1" CELLPADDING="2" CELLSPACING="0" BORDERCOLOR="#FFFFFF">
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 Dim cmdMain
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Dim the variable to hold the command object
 
 </td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 Set cmdMain = Server.CreateObject("ADODB.Command")
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Create the command object from the ADODB library
 
 </td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 cmdMain.CommandText="Select Question, Answer from FlashCards where CardID<=30"
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Set the query for the command. This could also be a table name, or a stored procedure.
 Depending on the provider, you may also need to set the CommandType property for the object.
 
 </td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 Set cmdMain.ActiveConnection = conDB
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Set the active connection for the command object.
 
 </td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 Set Session("CMD") = cmdMain
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Set the session level variable "CMD" equal to the command object. This will persist the
 command for the duration of the session, or until it is removed programmatically.
 
 </td>
 </tr>
</table>
</center>
 
<center><a href="code.asp?source=/bret/resume/adotutorial/copyofglobal.asa">View the actual global.asa file for this site</a></center>

For the above code segment, remember again that it is in the global.asa file, in the
Session_OnStart subroutine.

You may see now, how multiple command objects could be created for various frequently used queries. Then
when you needed to execute a given pre-defined query, you could just open a recordset object using the
command object for that query.

Now that our command object has been created, lets look at the properties for it.
The table below shows the actual properties for the Session("CMD") object in this tutorial's
ASP application. As with the connection object, we have specified only a few properties ourselves. The rest of theses attributes are
set to their default values, or they were populated by ADO based on the information in the connection object that we specified
with the ActiveConnection property:

<center>
<table WIDTH="90%" BORDER="1" CELLPADDING="2" CELLSPACING="0" BORDERCOLOR="#FFFFFF">
 <tr>
 <th COLSPAN="2" BGCOLOR="#C0C0C0">Session("CMD") Properties</th>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">ActiveConnection</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=cmdMain.ActiveConnection%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">CommandText</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=cmdMain.CommandText%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">CommandTimeout</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=cmdMain.CommandTimeout%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">CommandType</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=cmdMain.CommandType%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">Prepared</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=cmdMain.Prepared%></td>
 </tr>
</table>
</center>




<a NAME="RECORDSET"></a>

The Recordset Object: <a HREF="default.asp#top">top</a>

Now we get down to the meat of the matter. The recordset is where you will do most of your
interaction with the data. The recordset is very similar to the recordset object from the
Microsoft Data Access Objects (DAO) model. If you are familiar with DAO recordsets, you will
be right at home with the ADO recordset object.

There are some differences though depending on how you create the recordset. Two options that
can have a great deal to do with your success are the CursorType and LockType properties. In the
code segment below, we specify these properties in the Open method of the recordset. You could
also specify them using the actual properties before you used the Open method. I will leave it
up to you to review the ADO documentation for the various options. I generally use a static
cursor type (adOpenStatic, or 3) and an optimistic immediate lock type (adLockOptimistic, or 3).

The recordset is basically a 'cursor'. You can use standard move type methods (MovePrevious, MoveNext, MoveFirst, MoveLast)
as well as absolute positioning by a records ordinal value or by 'pages'. A page is a determined number
of records in the recordset. The 'page' size (in number of records per page) is set using the 'PageSize' property of the record set.
'PageCount' will return the number of pages (that are 'PageSize' records long) that exist in the recordset. Then you can use the
AbsolutePage property to set the current page of the recordset.

You should review the ADO documentation for the recordset object, or any of the above objects
for that matter, to gain a better understanding of the objects properties, methods, and
capabilities.

The code to create, and persist the recordset at the session level is put into the
Session_OnStart event handler in the global.asa file. The code to create our recordset
object looks like this:

<center>
<table WIDTH="90%" BORDER="1" CELLPADDING="2" CELLSPACING="0" BORDERCOLOR="#FFFFFF">
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 Dim rsData
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Dim the variable to hold the recordset object
 
 </td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 Set rsData = Server.CreateObject("ADODB.Recordset")
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Create the recordset object from the ADODB library
 
 </td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 rsData.Open cmdMain,,adOpenStatic,adLockOptimistic
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Open the recordset. Here we use the command object that we just created. It gives the query, and
 the active connection for the data. Notice the second parameter was skipped in this call. If we
 weren't using a command object to specify the query and active connection, we would have had the active
 connection specified there. However, because we are using the command object, it specifies the active
 connection for us.
 
 </td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 Set Session("DATA") = rsData
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Set the session level variable "DATA" equal to the recordset object. This will persist the
 recordset for the duration of the session, or until it is removed programmatically.
 
 </td>
 </tr>
</table>
</center>
 
<center><a href="code.asp?source=/bret/resume/adotutorial/copyofglobal.asa">View the actual global.asa file for this site</a></center>

For the above code segment, remember again that it is in the global.asa file, in the
Session_OnStart subroutine.

Now that our recordset object has been created, lets look at the properties for it.
The table below shows the actual properties for the Session("DATA") object in this tutorial's
ASP application. As with the connection and command objects, we have specified only a few properties ourselves. The rest of theses attributes are
set to their default values, or they were populated by ADO based on the information in the command object that we specified
when we opened the recordset.

<center>
<table WIDTH="90%" BORDER="1" CELLPADDING="2" CELLSPACING="0" BORDERCOLOR="#FFFFFF">
 <tr>
 <th COLSPAN="2" BGCOLOR="#C0C0C0">Session("DATA") Properties</th>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">AbsolutePage</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.AbsolutePage%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">AbsolutePosition</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.AbsolutePosition%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">ActiveConnection</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.ActiveConnection%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">BOF</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.BOF%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">EOF</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.EOF%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">Bookmark</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.Bookmark%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">CacheSize</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.CacheSize%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">CursorType</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.CursorType%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">EditMode</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.EditMode%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">Filter</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.Filter%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">LockType</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.LockType%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">MaxRecords</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.MaxRecords%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">PageCount</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.PageCount%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">PageSize</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.PageSize%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">RecordCount</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.RecordCount%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">Source</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.Source%></td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">Status</td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF"><%=rsData.Status%></td>
 </tr>
</table>
</center>




<a NAME="TOGETHER"></a>

Putting it All Together: <a HREF="default.asp#top">top</a>

I know you are anxious to actually work with the data, but before we can do that, there is one
more thing we have to do. We have been storing all of our objects at the session level. When
the user requests an ASP page, we need to retrieve those objects from the session so that we can
use them within a page. We do this by declaring some local variables, and then setting them equal
to the session level objects. Here is the code that we use in this page.

<center>
<table WIDTH="90%" BORDER="1" CELLPADDING="2" CELLSPACING="0" BORDERCOLOR="#FFFFFF">
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 Dim conDB
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Dim the local variable to hold the connection object that we will get from the session
 
 </td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 Dim cmdMain
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Dim the local variable to hold the command object that we will get from the session
 
 </td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 Dim rsData
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Dim the local variable to hold the recordset object that we will get from the session
 
 </td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 Set conDB = Session("CON")
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Set the local variable to the Session level object. Now we have a variable that we
 can use to interact with the connection.
 
 </td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 Set cmdMain = Session("CMD")
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Set the local variable to the Session level object. Now we have a variable that we
 'can use to interact with the command object.
 
 </td>
 </tr>
 <tr>
 <td VALIGN="TOP" BGCOLOR="#F0F0F0">
 Set rsData = Session("DATA")
 </td>
 <td VALIGN="TOP" BGCOLOR="#F0F0FF">
 
 'Set the local variable to the Session level object. Now we have a variable that we
 'can use to interact with the recordset.
 
 </td>
 </tr>
</table>
</center>


I think we have had enough of creating objects, lets actually talk to the database! The steps that
we took above have left us with a recordset that contains the contents of the <%=cmdMain.CommandText%>
query. We can use some quick VBScript code to show the contents of that query in an HTML table.

I have already developed an ASP function to do this. The function is stored in the
<a href="code.asp?source=/bret/resume/adotutorial/datautils.asp">datautils.asp</a> include file.

The table that is produced by the Data2HTML routine is below. To see the actual code,
<a href="code.asp?source=/bret/resume/adotutorial/datautils.asp">click here.</a>:
 Note: If you have been playing with customquery.asp you should <a href="reset.asp">reset the query</a> now

<%
 Data2HTML rsData
%>


To wrap it all up in a pretty little package, I have created a separate ASP page that allows you to enter a custom query to run
against the flash card database. The <a HREF="customquery.asp">customquery.asp</a> page takes the concepts that we have outlined in
this page, and puts them to a better use. <a HREF="customquery.asp">Check it out</a>, I am sure you will get a kick out of it!

<a HREF="customquery.asp">CLICK HERE TO RUN THE CUSTOMQUERY.ASP PAGE</a>

<hr>
<center>
Developed By
 
<a HREF="http://www.netconnex.com/"><img SRC="./images/mininetconnexlogo.gif" ALT="Net Connex" WIDTH="86" HEIGHT="32" BORDER="0" ALIGN="ABSMIDDLE"></a>

<a NAME="VIEWSOURCE"></a>

View code for.... 
<a href="code.asp?source=/bret/resume/adotutorial/default.asp">this page</a> -
<a href="code.asp?source=/bret/resume/adotutorial/copyofglobal.asa">global.asa</a> -
<a href="code.asp?source=/bret/resume/adotutorial/ncheader.asp">ncheader.asp</a> -
<a href="code.asp?source=/bret/resume/adotutorial/adovbs.asp">adovbs.asp</a> -
<a href="code.asp?source=/bret/resume/adotutorial/datautils.asp">datautils.asp</a>
 
</center>

</body>
</html>