首页 > 应用开发 > IT综合 > Working with MS Access Stored Procedures in VB.NET Montaque(转贴) (转)

Working with MS Access Stored Procedures in VB.NET Montaque(转贴) (转)

原创 IT综合 作者:worldblog 时间:2007-12-12 11:29:00 0 删除 编辑
Working with MS Access Stored Procedures in VB.NET Montaque(转贴) (转)[@more@]Working with MS Access Stored Procedures in vb.NET. Part 1
by ASPx?aid=9">David Wasserman, MCP

Article source code:


In the more recent releases of microsoft Access, great effort has gone into making this product a full-featured relational database system. Stored procedures, a functionality usually associated with enterprise database systems such as sql SERVER, can now be found in Access. Stored procedures in Access have been available since Access 2000 and are native to the Jet 4 Database Engine. If you're accustomed to using stored procedures in SQL SERVER, then you'll be right at home with how they're used in Access. However there are some limitations to keep in mind. I'll discuss those later on.

This article will be broken down into two parts. Part one will describe in detail how to create stored procedures in Access using and Visual Basic.NET. Part two will demonstrate how to utilize the stored procedures created in part one by assembling a data access tier that can be modelled and used in your own applications. The code in this article has been tested using Access 2002, although it should also work with Access 2000.

How do stored procedures work in Access?

Unlike other objects in Access, stored procedures have no interface and cannot be created or run through the Access User Interface. The way to get them into your database is to simply code them. I'll show how that's done in ADO.NET.

When a stored procedure is added to an Access Database, the Jet Engine reworks the stored procedure syntax into a query object. To an Access developer this may sound like unnecessary work to code a query. However, it does have its advantages. Consider an application that has to break out into different versions when maintaining both an Access Database and a SQL Server Database. Using stored procedures will make it easier to write the code for the database tier of the application as the program will change very little between the different versions.

Creating Stored Procedures

To demonstrate, I'll first show how to create the SQL statements to create stored procedures. At the end of the article I'll show the entire code needed to run these statements against the database. Using the Northwind database that comes with Access, four stored procedures will be created. Focusing on the Products table for all of them, let's start off with the easiest one; select all data of each row in the table. To create the stored procedure, execute the following SQL statement against the database:

"CREATE PROC procProductsList AS SELECT * FROM Products;"

The statement: "CREATE PROC procCustomerList" is the part that actually creates the stored procedure. The part following "AS" can be any valid SQL Statement.

Often in a stored procedure you'll want to pass a value to be used in the query. Consider that you may want to delete a record based on a particular ProductID. The following stored procedure shows how to do just that:

"CREATE PROC procProductsDeleteItem(inProductsID LONG)" & _
"AS DELETE FROM Products WHERE ProductsID = inProductsID;"

On the first line, notice the parenthesis right after the CREATE PROC declaration. There is a parameter defined as a Long value. This is where you add the variable to delete the record in question.

The next two statements show how to create an add and an update stored procedure for the Products table respectively. Note that not all fields are included for the sake of brevity:

"CREATE PROC procProductsAddItem(inProductName VARCHAR(40), " & _
"inSupplierID LONG, inCategoryID LONG) " & _
"AS INSERT INTO Products (ProductName, SupplierID, CategoryID) " & _
"Values (inProductName, inSupplierID, inCategoryID);"
"CREATE PROC procProductsUpdateItem(inProductID LONG, " & _
" inProductName VARCHAR(40)) " & _
"AS UPDATE Products SET ProductName = inProductName " & _
" WHERE ProductID = inProductID;"

Notice that a comma separates each parameter when more than one is specified.


There are some limitations you may encounter here, especially if you're used to the power of SQL Server.

  • Output parameters cannot be used.
  • Don't use the @ character. The @ character is often used in Transact SQL (SQL Server), where it represents a local variable. Access doesn't always convert this character and will sometimes leave it out. This can cause esoteric bugs which can lead to premature hair loss.
  • Temporary tables are not available in Access.
  • I suspect many of the options available in Transact SQL are not available in Access as it's not Transact SQL compatible.


Hopefully, this article has provided some guidance in a nearly undocumented area of Access and Jet not yet explored by most. For more information on how the ADO.NET code works in the CreateStoredProc subroutine, see aspx?cid=1&y=2002&m=2&d=6">Getting Started with ADO.NET by Gurneet Singh. The following is a complete listing of all code presented in this article:

com -->

Imports System Imports System.Data Imports System.Data.Oledb Module CreateSP  Sub Main()  ProductsProcs()  End Sub  ' Products Stored Procs to be added to the db.  Sub ProductsProcs()  Dim sSQL As String  ' procProductsList - Retrieves entire table  sSQL = "CREATE PROC procProductsList AS SELECT * FROM Products;"  CreateStoredProc(sSQL)  ' procProductsDeleteItem - Returns the details (one record) from the   ' JobTitle table  sSQL = "CREATE PROC procProductsDeleteItem(@ProductID LONG) AS " _  & "DELETE FROM Products WHERE ProductID = @ProductID;"  CreateStoredProc(sSQL)  ' procProductsAddItem - Add one record to the JobTitle table  sSQL = "CREATE PROC procProductsAddItem(inProductName VARCHAR(40), " _  & "inSupplierID LONG, inCategoryID LONG) AS INSERT INTO " _  & "Products (ProductName, SupplierID, CategoryID) Values " _  & "(inProductName, inSupplierID, CategoryID);"  CreateStoredProc(sSQL)  ' procProductsUpdateItem - Update one record on the JobTitle table  sSQL = "CREATE PROC procProductsUpdateItem(inProductID LONG, " _  & "inProductName VARCHAR(40)) AS UPDATE Products SET " _  & "ProductName = inProductName WHERE ProductID = inProductID;"  CreateStoredProc(sSQL)  End Sub  ' Execute the creation of Stored Procedures  Sub CreateStoredProc(ByVal sSQL As String)  Dim con As OleDbConnection  Dim cmd As OleDbCommand = New OleDbCommand()  Dim da As OleDbDataAdapter  ' Change Data Source to the location of Northwind.mdb on your local   ' system.  Dim SCOnStr As String = "PROVIDER=Microsoft.Jet.OLEDB.4.0;Data " _  & "Source=C:Program FilesMicrosoft " _  & "OfficeOffice10SamplesNorthwind.mdb"  con = New OleDbConnection(sConStr)  cmd.Connection = con  cmd.CommandText = sSQL  con.Open()  cmd.ExecuteNonQuery()  con.Close()  End Sub End Module

Working with MS Access Stored Procedures in VB.NET. Part 2

Article source 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.

Imports System Imports System.Data Imports System.Data.OleDb

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.

Then next line of code starts the definition of the Class:

Public Class DBTier

Here we've named the Class DBTier and have given it a modifier of Public, thus making it very accessible from other code modules. After the class is defined all properties are declared:

Shared connectionString As String = _  "PROVIDER=Microsoft.Jet.OLEDB.4.0;Data Source=C:Program " _  & "FilesMicrosoft OfficeOffice10SamplesNorthwind.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 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.

Sub ProductsDeleteItem(ByVal ProductID As Integer)

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.

Dim con As OleDbConnection Dim cmd As OleDbCommand = New OleDbCommand() Dim paramProductID As New OleDbParameter()

Command and connection objects are initialized:

con = New OleDbConnection(connectionString) 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 paramProductID  .ParameterName = "inProductID"  .OleDbType = OleDbType.Integer  .Size = 4  .Value = ProductID End With cmd.Parameters.Add(paramProductID)

The last part actually calls the stored procedure.

cmd.CommandText = "EXECUTE procProductsDeleteItem" 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.

Entire DBTier.vb source code:

Imports System Imports System.Data Imports System.Data.OleDb ' Functions and subroutines for executing Stored Procedures in Access. Public Class DBTier  ' Change Data Source to the location of Northwind.mdb on your local   ' system.  Shared connectionString As String = _  "PROVIDER=Microsoft.Jet.OLEDB.4.0;Data Source=C:Program " _  & "FilesMicrosoft OfficeOffice10SamplesNorthwind.mdb"  ' This function returns a dataset containing all records in  ' the Products Table.  Function ProductsList() As DataSet  Dim con As OleDbConnection  Dim da As OleDbDataAdapter  Dim ds As DataSet  Dim sSQL As String  sSQL = "EXECUTE procProductsList"  con = New OleDbConnection(connectionString)  da = New OleDbDataAdapter(sSQL, con)  ds = New DataSet()  da.Fill(ds, "Products")  Return ds  End Function  ' This Function adds one record to the Products table.  Sub ProductsAddItem(ByVal ProductName As String, _  ByVal SupplierID As Integer, ByVal CategoryID As Integer)  Dim con As OleDbConnection  Dim cmd As OleDbCommand = New OleDbCommand()  Dim paramProductName As New OleDbParameter()  Dim paramSupplierID As New OleDbParameter()  Dim paramCategoryID As New OleDbParameter()  con = New OleDbConnection(connectionString)  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  .Size = 4  .Value = CategoryID  End With  cmd.Parameters.Add(paramCategoryID)  cmd.CommandText = "EXECUTE procProductsAddItem"  con.Open()  cmd.ExecuteNonQuery()  con.Close()  End Sub  ' This function Updates a specific JobTitle Record with new data.  Sub ProductsUpdateItem(ByVal ProductID As Integer, _  ByVal ProductName As String)  Dim con As OleDbConnection  Dim cmd As OleDbCommand = New OleDbCommand()  Dim paramProductName As New OleDbParameter()  Dim paramProductID As New OleDbParameter()  con = New OleDbConnection(connectionString)  cmd.Connection = con  With paramProductID  .ParameterName = "inProductID"  .OleDbType = OleDbType.Integer  .Size = 4  .Value = ProductID  End With  cmd.Parameters.Add(paramProductID)  With paramProductName  .ParameterName = "inProductName"  .OleDbType = OleDbType.VarChar  .Size = 40  .Value = ProductName  End With  cmd.Parameters.Add(paramProductName)  cmd.CommandText = "EXECUTE procProductsUpdateItem"  con.Open()  cmd.ExecuteNonQuery()  con.Close()  End Sub  ' This function deletes one record from the Products table.  Sub ProductsDeleteItem(ByVal ProductID As Integer)  Dim con As OleDbConnection  Dim cmd As OleDbCommand = New OleDbCommand()  Dim paramProductID As New OleDbParameter()  con = New OleDbConnection(connectionString)  cmd.Connection = con  With paramProductID  .ParameterName = "inProductID"  .OleDbType = OleDbType.Integer  .Size = 4  .Value = ProductID  End With  cmd.Parameters.Add(paramProductID)  cmd.CommandText = "EXECUTE procProductsDeleteItem"  con.Open()  cmd.ExecuteNonQuery()  con.Close()  End Sub End Class


来自 “ ITPUB博客 ” ,链接:,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
  • 博文量
  • 访问量