Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1


Ratings: (0)|Views: 24|Likes:
Published by api-3841500

More info:

Published by: api-3841500 on Oct 18, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less





Database Tier - Code

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.

Database Tier - Code
It's now time to roll up our sleeves and get dirty with some code. The first thing after adding
an empty class declaration file is to pull in the proper .NET Framework libraries listed below.
Impo r t sSy s t em
Impo r t sSy s t em. Da ta
Impo r t sSy s t em. Da t a. OleDb

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.

Then next line of code starts the definition of the Class:
Pub l icC lassDBT i e r
Here we've named the Class DBTier and have given it a modifier ofPublic, thus making it very
accessible from other code modules. After the class is defined all properties are declared:
Sha redconnec t i o nS t r i n g
As Str ing=_
"PROVIDER=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Program "_
& "Files\Microsoft Office\Office10\Samples\Northwind.mdb"

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 theProductsDeleteItem

subroutine. After understanding how this subroutine works the others should be easy to
To start off the routine takes in one parameter, ProductID, which is an Integer representing
the Product to be deleted.
SubProductsDeleteIt em(ByVa lP r odu c t I DAs In teger
Next, all variables are declared. One for the connection, command and a parameter to be
passed into the stored procedure. This parameter is theProductID to be deleted.
Dimc on AsO l eDbConne c t i o n
Dimcmd AsO l eDbCommand= NewOleDbCommand()
Dimpar am Product ID As NewOleDbParameter()
Command and connection objects are initialized:
con= New OleDbConnection(connectionString)
cmd.Connection= con
TheparamProductID 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
Withpa r amP rodu c t I D

.ParameterName ="inProductID"
.OleDbType =OleDbType.Integer
.Size =4
.Value =Pro d u c tI D

End With
The last part actually calls the stored procedure.

cmd.CommandText= "EXECUTE procProductsDeleteItem"

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

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.

Entire DBTier.vb source code:

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->