Store Procwithvb
Store Procwithvb
Store Procwithvb
Introduction
Database Tier - Code
Introduction
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.
Top
The System Library is standard for most applications, and I make it a habit to include it in
almost all my code modules. The System.Data library is necessary for almost all database
access applications. The System.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 provider System.Data.SqlClient.
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.
After the connection string declaration you'll find there are three subroutines and one function.
The function returns a dataset with a listing of all products. It calls the stored procedure
procProductsList, created in part one of this article.
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 the ProductsDeleteItem
subroutine. After understanding how this subroutine works the others should be easy to
digest.
To start off the routine takes in one parameter, ProductID, which is an Integer representing
the Product to be deleted.
Next, all variables are declared. One for the connection, command and a parameter to be
passed into the stored procedure. This parameter is the ProductID to be deleted.
cmd.Connection = con
The paramProductID parameter properties are configured. Then the parameter is added to
the command object. In this case the parameter name in the stored procedure is
inProductID, it's an integer and the value is set to the ProductID passed into this
subroutine.
With paramProduc t ID
.OleDbType = OleDbType.Integer
.Size = 4
.Value = ProductID
End With
cmd.Parameters.Add(paramProductID)
con.Open()
cmd.ExecuteNonQuery()
con.Close()
Notice that the connection object only stays open long enough to carry out the stored
procedure and then closes immediately. This reduces any possible contention.
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
here.
The downloaded source code associated with this article includes the DBTier.vb file along with
some very basic forms to test the actual implementation of the class.
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.
' Change Data Source to the l o ca t i on o f Nor thw ind .mdb on your l o ca l
Dim da As OleDbDataAdapte r
Dim ds As DataSet
ds = New DataSet()
da.Fill(ds, "Products")
Retu rn ds
End Func t i on
cmd.Connection = con
With paramProductName
.ParameterName = "inProductName"
.OleDbType = OleDbType.VarChar
.Size = 40
.Value = ProductName
End With
cmd.Parameters.Add(paramProductName)
With paramSupplierID
.ParameterName = "inSupplierID"
.OleDbType = OleDbType.Integer
.Size = 4
.Value = SupplierID
End With
cmd.Parameters.Add(paramSupplierID)
With paramCategoryID
.ParameterName = "inCategoryID"
.OleDbType = OleDbType.Integer
.S ize= 4
.Value = CategoryID
End With
cmd.Parameters.Add(paramCategoryID)
con.Open()
cmd.ExecuteNonQuery()
con.Close()
End Sub
cmd.Connection = con
With paramProductID
.ParameterName = "inProductID"
.OleDbType = OleDbType.Integer
.Size = 4
.Value = ProductID
End With
cmd.Parameters.Add(paramProductID)
With paramProductName
.Pa ramete rName = "inProductName"
.OleDbType = OleDbType.VarChar
.Size = 40
.Value = ProductName
End With
cmd.Parameters.Add(paramProductName)
con.Open()
cmd.ExecuteNonQuery()
con.Close()
End Sub
cmd.Connection = con
With paramProductID
.ParameterName = "inProductID"
.OleDbType = OleDbType.Integer
.Size = 4
.Value = ProductID
End With
cmd.Parameters.Add(paramProductID)
cmd
. Execu teNonQuery ()
.con
C lose()
End Sub
End C lass