Welcome to part two of Access Stored Procedures. Part one [^] described in detail how to
create stored procedures in Access using ADO.NET and Visual Basic.NET. Part two will
demonstrate how to utilize the stored procedures created in part one by assembling a
Database Tier that can be modelled and used in your own applications. This article will
describe in detail one implementation of a Database Tier for Visual Basic.NET.
The main purpose of the Database Tier is to provide a gateway to the database via a class
module. This class module would act as the glue between the database and the application.
There are two main advantages to using a data tier to access your database. You will have the
ability to modify your underlying database technology (moving from MS Access to SQL Server
for instance) without affecting your application in a major way. You will also be placing a
control layer between your application and the database allowing you to ensure that all data is
properly "cleansed". The Database Tier in .NET applications would most likely consist of a class
module keeping in line with proper object-oriented coding conventions. Earlier versions of
Visual Basic would employ a Standard Module to do the job.
TheSystem Library is standard for most applications, and I make it a habit to include it in
almost all my code modules. TheSystem.Data library is necessary for almost all database
access applications. TheSystem.Data.OleDb is used specifically for OLEDB Database Providers
to which Microsoft Access belongs to. If we were using SQL Server we'd include the custom
SQL providerSystem.Data.SqlC lient.
Only one property is declared here as a string variable,connectionString. This variable
holds the connection string for the Northwind Access Database. Declaring the variable as
Shared defines it as "Class Variable". A class variable is associated with the class, not each
object instantiated from the class.
Next you'll find the three subroutines. There is one for each stored procedure; add, update and deletion of products. They're all similarly structured; each with a command, connection and required parameter(s) declared. As a sample, let's dissect theProductsDeleteItem
.Value =Pro d u c tI D
cmd.CommandText= "EXECUTE procProductsDeleteItem"
While the DBTier class included in this article clearly describes how to access the stored
procedures, it would need some enhancements to become quality production code since no
error handling has been added. There may also be the need to further enhance performance
In conclusion, I hope you have gained at least two things from these articles. One being that
stored procedures are alive and well in Microsoft Access, although not without their limitations.
The second thing to walk away with here is understanding the need to break down an
application's data access into separate classes, subroutines and functions. This makes
maintenance and upgrades much easier to implement.
This action might not be possible to undo. Are you sure you want to continue?