Database Application
Exam #2 Practice Test (with exams)

Exam 2  
Exam 2 – Wednesday, Nov 28  
 
This test includes materials from chapter 13 and several handouts. I would expect you to be able 
to:  
 
1. 	Describe Microsoft's ODBC and OLE DB architecture  

ODBC stands for open database connectivity standard.  It involves the application 
program, driver manager, DBMS driver, and data source components.

Application program is the "front-end".  Its primary purpose is to provide the graphic 
user interface although it can, and often does, process portions of the database 
application.

The driver manager acts as a mediator between the application program and the DBMS.  
It analyzes requests made by the application (client) and determines the DBMS type 
being used on the server side to process a given ODBC data source so that it can load 
the appropriate driver for that DBMS.

A DBMS driver processes ODBC requests and submits specific SQL statements to a 
given type of data source.

The data source components of the ODBC architecture include the database itself and 
its associated DBMS.

OLE DB stands for 

See paragraph 3 of summary on p. 369.
 
2. 	Describe the ADO object model and provide examples of its use.

	The ADO object model is built "on top of" the OLE DB object model.

ADO stands for Active Database Object.  The ADO object model begins at its highest 
level with a Connection object.  This object establishes a connection to the specified 
database.

At the next level down of the model are the Recordset object, the Command object, 
and the Errors object.  These three objects depend on the Connection object.  In other 
words, there must be an open connection to the database for them to work.

The Recordset object contains the results of a query and is used to view and/or update 
the results of that query.

The Command object is used to execute queries and stored procedures.

The Errors object is a collection of any and all errors generated during the execution of 
an ADO object statement.  The Errors object belongs to the Connection object as 
opposed to belonging to Recordset object.

The objects at the next level down include the Fields object and the Parameters object.  
They depend on the Recordset object and the Commands object respectively.  The 
Fields object references the specific data contained within the returned recordset in the 
Recordset object.  The Parameters object sets up the parameters that are passed to the 
Command object.

Examples:
?	Connection object – In our project, connDB is an example of a Connection 
object.
?	Recordset object – In our project, rsCustomer is an example of a Recordset 
object.
?	Command object – In our project, we used the word "comm" to represent the 
Command object – although we did use different properties to set up the different 
pieces of the command object.  For example, in "Set comm.ActiveConnection = 
conDB", we're specifying which connection to use.
?	Errors object – In our project, we are not using ADODB to manage our errors 
because we are already managing them in other ways.
?	Fields object – In our project, we are not using ADODB Fields objects because 
we are not managing the results of our queries at the "field" level.  We're dealing 
with the results of our queries at a recordset level.  In other words, we are never 
extracting data from one particular field (column).  We are always dealing with 
entire records (rows) at a time.
?	Parameters object – In our project, we have some input parameters and some 
output parameters for each Command object.