Microsoft Access Team Blog : SQL Server

Handling the SQL Server bigint data type in Access 2007 using ADO

Mike Stowe — Thu, 11 Jun 2009 01:31:28 GMT

Today’s guest blogger is Vinny Malanga. Vinny is the CTO of IMI Software, Inc., which specializes in software development for the property management industry.

I recently received a call from a client asking for help on how to use the SQL Server bigint data type in a disconnected Access .accdb file. Here’s the scenario:

There’s a SQL Server table that is using the bigint data type as an identity column. In this scenario, the Access database is completely disconnected from the SQL Server 2008 database. There is no use of ODBC or linked tables. All data access is handled using ADO.

As explained in SQL Server 2008 Books Online the range of the bigint data type is -2^63 (-9,223,372,036,854,775,808) to 2^63-1 (9,223,372,036,854,775,807). The problem is that there is no equivalent Access data type to the SQL Server bigint data type. But, you are not out of luck. There are a couple of ways that you can handle this. Both options are explained below.

The first option is to have all stored procedures or views which return the bigint value to Access explicitly cast the bigint value to a varchar. Access can then utilize the data as a string value. When sending the value back to SQL Server (such as when updating or deleting a record), the stored procedure simply casts the string back to a bigint so it can be used appropriately in SQL Server.

The second option is to utilize the Variant data type in Access. I know what you may be thinking at this point. At first glance, many of you may not like the sound of this, and as a general rule, I tend to agree, but it is worth exploring this option. By taking this approach, there is no casting in SQL Server necessary. The Variant data type can hold the bigint value that SQL Server sends to Access because the Decimal data type is a subtype of the Variant data type. You can’t explicitly declare a Decimal data type in Access but the Variant data type does store the value as a decimal. You can see this by running the VarType(VarName) function. The result is 14 which is the VB constant for vbDecimal. You could also run the TypeName(VarName) function which returns Decimal. I’ve included these methods in the sample access database in the cmdGetName_Click() event. Just uncomment them and the result will print in the debug window.

Another small caveat to using a variant is if you are going to display the value in a textbox. The large bigint values will display in scientific notation. For example, if you are displaying the bigint value 9223372036854775807, an Access textbox will display this as 9.22337203685478E+18. However, the actual value is stored appropriately so this isn’t an issue if the field is hidden. For display purposes though, you could cast the value to a string using CStr(Expression) when binding to the textbox (again, a little more overhead), or simply display the value in a label control.

As a general rule, using variants can degrade performance. Since the data type isn’t explicitly declared, VBA has the additional overhead of maintaining which data type it is actually storing. Also, variants are large, 16 bytes so they have a higher memory footprint. However, variants are there for a reason and sometimes they do have their purpose. This could be one of them. I’m not totally opposed to this method, but personally I try to avoid using the Variant data type when another option is available. So, personally, I tend to gravitate toward the first option.

I’ve supplied some SQL scripts and a sample Access database applying both methods There are also some examples in the sample database on the use of classes, disconnected ADO Recordsets, and general object oriented programming principles.

Here are the scripts to create the objects in a SQL Server database.

-- 1 Create a table:
-- I have set the identity to begin at the largest bigint value
-- for demonstration purposes.
CREATE TABLE [dbo].[tblName](
    [RecordID] [bigint] IDENTITY(9223372036854775807,-1) NOT NULL,
    [Name] [varchar](50) NULL,
 CONSTRAINT [PK_tblName] PRIMARY KEY CLUSTERED 
(
    [RecordID] ASC
)
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, 
       ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

-- Create four Stored Procedures.
CREATE PROCEDURE [dbo].[procGetNameUsingString] 
AS
BEGIN
    SET NOCOUNT ON;
    -- bigint range is -9223372036854775808 to 9223372036854775807

    -- Cast RecordID to varchar(19) when sending to Access
    -- 19 is the number of characters needed to hold the largest
    -- length bigint value. Use 20 if you're going to use negative
    -- numbers to account for the negative sign.
    SELECT CAST(RecordID AS varchar(19)) AS RecordID, Name FROM tblName
END
GO

CREATE PROCEDURE [dbo].[procGetNameUsingVariant] 
AS
BEGIN
    SET NOCOUNT ON;
    SELECT  RecordID, Name FROM tblName
END
GO

CREATE PROCEDURE [dbo].[procUpdateNameUsingString]
    (
        @RecordID        varchar(19),
        @Name            varchar(50),
        @ReturnValue    bit OUTPUT
    )
AS
BEGIN
    SET NOCOUNT ON;
    -- Declare a variable to hold the bigint value
    -- and assign it the result of casting the incoming
    -- string representation of RecordID back to a bigint value.
    DECLARE @RecordIDBigInt bigint
    SET @RecordIDBigInt = CAST(@RecordID AS bigint)
    -- Update the record using the bigint value.
    UPDATE tblName
    SET Name = @Name
    WHERE RecordID = @RecordIDBigInt
    
    SET @ReturnValue = @@ROWCOUNT
END
GO

CREATE PROCEDURE [dbo].[procUpdateNameUsingVariant]
    (
        @RecordID        bigint,
        @Name            varchar(50),
        @ReturnValue    bit OUTPUT
    )
AS
BEGIN
    SET NOCOUNT ON;

    UPDATE tblName
    SET Name = @Name
    WHERE RecordID = @RecordID
    
    SET @ReturnValue = @@ROWCOUNT
END
GO

-- Create a view (example if using views
-- rather than stored procedures).
CREATE VIEW [dbo].[vwGetNameUsingString]
AS
SELECT     RecordID, CAST(Name AS varchar(19)) AS Expr1
FROM         dbo.tblName
GO

Once you’ve run the scripts, your SQL database will contain one new table, four new stored procedures, and one new view. You’ll want to add a record to the newly-created table to make use of the form in the sample Access database.

You can download the sample Access database from here. You should change the connection string in the Connect subroutine of the clsDataAccess module to suit your environment. Note that the code requires a reference to the Microsoft ActiveX Data Objects 6.0 Library. The sample database already contains the reference; this is something to keep in mind if you implement the class in your database.

Channel 9 video about Access and SQL Server Migration

Clint Covington — Wed, 18 Mar 2009 09:00:18 GMT

Luke Chung from FMS recently talked on Channel 9 about his view of Access solutions -- where they fit well, what challenges users and developers often face in creating and maintaining them, and how they have evolved from standalone desktop solutions to having the capability to be integrated with web-based and SharePoint centric solutions. He further explains primary reasons why some Access database solutions are migrated to SQL Server database based solutions, what different approaches are used to carry out migrations, and how to get started with the migration process when a large number of Access databases are involved.

You can get more info from FMS about upsizing here.

Luke has also recently written about Top Features of Microsoft Access 2007 that Aren’t Available in Prior Versions. Many of you might find it interesting.

Using SQL Server 2008 Table-Valued Parameters (TVPs) from Access

Clint Covington — Wed, 28 Jan 2009 20:13:00 GMT

Today’s guest writer is Mary Chipman. Mary is a programmer-writer for the Data Programmability team at Microsoft and co-author of the classic Microsoft Access Developer's Guide to SQL Server.

Table-valued parameters (TVPs) in SQL Server 2008 provide an easy way to marshal multiple rows of data from a client application to SQL Server without requiring multiple round trips or special server-side logic for processing the data. TVPs come in handy when you want to code explicit transactions inside of stored procedures, performing multiple data operations as a single unit of work. You can encapsulate multiple rows of data in a single parameterized command. The incoming data rows are stored in a table variable that can then be operated on by using Transact-SQL.

In versions of SQL Server prior to SQL Server 2008 you had to jump through a lot of hoops to pass in and process multiple rows of data. Stored procedure input parameters did not accept arrays or structured data, so developers used such techniques as bundling multiple data values into delimited strings or XML documents. Those text values then needed to be processed, which required that you validate the data structures and unbundle the values. With TVPs, you simply pass in the rows of data to be operated on. This not only frees server resources to focus on set-based operations, making your transactions more scalable and efficient, but it also simplifies your server-side Transact-SQL code.

Using TVPs from Access makes sense only for a limited set of scenarios, such as a store-and-forward application that operates on data locally in Access and then posts changes to SQL Server, "unbound" applications that interoperate with stored procedures, and transactional applications such as orders-line items in which all rows need to be either committed or rolled back to guarantee data consistency. The default way of updating server-side data—one row at a time—is adequate in most data access scenarios. This article discusses how you can use TVPs as an alternative, as well as the drawbacks of using this technique in Access.

How TVPs Work

Table-valued parameters are based on strongly-typed table structures that are defined by using the Transact-SQL CREATE TYPE statement. In order to use a TVP, you must first create a table type and define its structure in the database. The table type functions as a container for the structured data rows that you pass to the server, so it mirrors the data structure of the underlying data you want to use it with. Once you've defined the table type, you can then use it to define an input parameter for a stored procedure or Transact-SQL statement.

You can work with TVPs directly in Transact-SQL code, or by using either ADO.NET or SQL Server Native Client objects. In ADO.NET, the SqlParameter class has been extended to take a DataTable as a value. The SQL Server Native Client OLE DB API accomplishes the same thing by leveraging the COM IRowset interface along with a new implementation that allows buffering.

The downside for Access developers is that the ADO API has not been updated to support TVPs directly through ADO Parameter objects. Unless you want to program directly against the SQL Server Native Client API by declaring and calling API functions, that leaves you with a single option: pass-through queries running Transact-SQL, which you can modify programmatically using a DAO QueryDef object.

TVPs and Access Pass-Through Queries

Access pass-through queries, as the name implies, allow you to bypass the Jet database engine and to send Transact-SQL code directly to SQL Server for execution. Although pass-through queries can be used to return records, this feature is not available if you want to use table-valued parameters. To use TVPs, you must set the query's Returns Records property to No or Access will raise an error. Unfortunately, this means that you will be unable to return any information whatsoever through the pass-through query mechanism. If you need to get information back from the server, such as new identity values, you will need to execute a separate query to accomplish that.

Pass-through queries are most easily manipulated programmatically using the DAO QueryDef object. In addition to setting Returns Records to No, you will need to set the Connect property to a valid ODBC connection string and the SQL property to a string value that contains the Transact-SQL statements you are passing to the server for processing.

TVPs can be especially useful if you are working with an "unbound" application that relies on code execution and stored procedures rather than using bound controls to manipulate data. The tradeoff is that your client code in Access needs to be more complex, as it must parse row data into properly delimited Transact-SQL statements. The benefits include a simpler server-side programming model with more maintainable stored procedure code, faster performance from set-based operations, and better scalability for larger data volumes. Another consideration is that TVPs are server-side objects, therefore they can be used from multiple client applications, not just Access.

TVP Walkthrough

Here are the steps for creating a simple proof-of-concept example using the Northwind database in SQL Server 2008.

The example creates a table structure that is saved in the database and used to insert multiple new rows into the Categories table. Note that the Categories base table contains an identity column. It also does not have a unique index defined on CategoryName, which would allow duplicate categories to be inserted. These are both potential problems that you'll need to anticipate and work around in a real-world situation. Execute the following Transact-SQL statements in SQL Server Management Studio to create the CategoryTableType.

Use Northwind
GO
CREATE TYPE dbo.CategoryTableType AS TABLE
( CategoryName nvarchar(15), CategoryDescription ntext )
GO

Once the CategoryTableType is created, you can use it to define a stored procedure input parameter. The following usp_InsertCategory stored procedure takes the CategoryTableType as an input parameter, which is defined using the READONLY keyword. Other features of the stored procedure include:

An output parameter returns information to the caller. Even though you can't obtain it from the pass-through query, it's possible that you might also want to call the stored procedure from a .NET application, where the output parameter value would be available.
Try/Catch error handling, which was introduced in SQL Server 2005. Again, you can't use this feature from a pass-through query, but you could conceivably call the stored procedure from another client.
An explicit transaction using BEGIN TRAN, COMMIT, and ROLLBACK statements. This ensures that all rows inserted into the Categories table will commit in a single transaction, or all will be rolled back. For example, if you have 10 rows, and there is an error with only 1 of them, then none of the rows will be inserted. If you do not have an explicit transaction, 9 out the 10 rows will be committed, but you will have no way of knowing which one was the problem row that didn't make it.
In the Catch block, the code calls the @@TRANCOUNT function to see if a transaction is active. This allows you to avoid triggering another error if you attempt a rollback without an active transaction.

Execute the following Transact-SQL statements in the SQL Server Management Studio window to create the usp_InsertCategory stored procedure.

CREATE PROCEDURE dbo.usp_InsertCategory 
	(@tvpNewCategories dbo.CategoryTableType READONLY,
	@ReturnMessage nvarchar(255) = NULL OUTPUT)

AS
SET NOCOUNT ON
BEGIN TRY
	BEGIN TRAN
		INSERT INTO dbo.Categories (CategoryName, Description)
		SELECT CategoryName, CategoryDescription FROM @tvpNewCategories 
		IF @@ROWCOUNT = 0
			RAISERROR ('No Categories inserted.', 16, 1)
	COMMIT
	SELECT @ReturnMessage='Categories inserted.';
END TRY

BEGIN CATCH
	IF @@TRANCOUNT > 0
		ROLLBACK
		SELECT @ReturnMessage = ERROR_MESSAGE() +
			' Severity=' + CAST(ERROR_SEVERITY() AS nvarchar(2))
END CATCH
GO

In Access, create a pass-through query and set the Returns Records property to No. Set the ODBC Connect Str property to a DSN or valid ODBC connection string.

Paste the following Transact-SQL statements into the SQL pane of your pass-through query. You can also test these statements from SQL Server Management Studio query window—the result will be the same. The only difference is that in Management Studio you will be able to see the return message.

DECLARE @ReturnMessage nvarchar(255)
DECLARE @catType CategoryTableType
INSERT INTO @catType
EXEC ('
SELECT ''Organic'', ''Organically grown produce and grains''
SELECT ''Conventional'', ''Non-organically grown produce and grains''
SELECT ''Irish'', ''Mrs. O''''Leary''''s creamery products''
')
EXEC dbo.usp_InsertCategory @catType, @ReturnMessage OUTPUT;
SELECT @ReturnMessage as ReturnMessage

What these Transact-SQL statements are doing is packaging up the values you want to pass to the usp_InsertCategory stored procedure, and inserting the proper escape characters so that it can be processed without triggering a syntax error. When you execute the pass-through query, these statements will be passed directly to SQL Server to be parsed and executed. None of the statements will be processed by Jet or ODBC. Note that I've added an "Irish" category to demonstrate the correct syntax for passing apostrophes (single quotes). This is the sort of string processing you'll need to handle in your VBA code as you concatenate row values with Transact-SQL statement syntax. For example, you could use the VBA Replace function to find and double up any apostrophes.

Before you execute the query, open a SQL Server Profiler trace. Execute the query, and you will see that the statements are indeed passed through directly to SQL Server.

Enter the following statements into the SQL Server Management Studio window:

SELECT CategoryID, CategoryName, Description from dbo.Categories

You will see that the new rows have been inserted. If you define a unique index on the CategoryName column and then attempt to execute the InsertCategory stored procedure again, you will see the error message only if you execute the statements from SQL Server Management Studio, but nothing if you execute the Access pass-through query. You can examine the Profiler trace to verify that the statements have in fact been sent from Access.

Summary

You'll probably only be interested in calling TVPs from Access pass-through queries for a limited number of scenarios that need to pass multiple rows of structured data to SQL Server to be processed on the server. There are several drawbacks to this technique: you won't get any design-time syntax checking, and run time error handling will be limited. In addition, you won't be able to retrieve new identity column values from within the pass-through query, because it can't return any data. You can work around these limitations, but it will require making specific design decisions as well as coding workarounds. The main benefit is that you are making your database transactions more scalable and efficient by performing iterative string processing in your client code, freeing up server resources to focus on set-based operations.

Bio

Mary Chipman is a programmer-writer for the Data Programmability team at Microsoft. She was recently profiled in Women in Technology for TechEd Online at http://msdn.microsoft.com/en-us/events/teched/cc510243.aspx. You can find the online panel she hosted at TechEd 2008 by going to http://msdn.microsoft.com/en-us/events/teched/cc676818.aspx and searching for: "Are we there yet? Successfully navigating the bumpy road from Access to SQL Server". Mary will also be presenting at TechEd 2009 (http://www.msteched.com) on the topic of working with SQL Server from Access.

Announcement: Storing Access apps and data in the cloud

Clint Covington — Tue, 28 Oct 2008 19:00:00 GMT

Today’s guest writer is Liam Cavanagh from the Sync Framework and SQL Services team. They are doing some cool stuff that allows Access developers to store their app and data in the cloud using SQL Server Data Services. Liam is looking for people that want to beta test an upcoming release early next year. --Clint

Today at PDC we are announcing Codename “Huron”, a set of synchronization experiences built on top of the sync functionality in SQL Data Services’ cloud database and the Microsoft Sync Framework to provide business database sharing. Business database sharing offers a simple way to scale data to large numbers of users while not parting from the investment made in current technologies. It also enables users to subscribe and then edit the data locally in the format of their choice whether that is Office Access, SQL Server Express or SQL Server Compact and then push changes into SQL Data Services. The first end-to-end experience we will provide is for Office Access and will allow users to:

Publish databases to the cloud along with reports, forms and objects
Subscribe to published data and automatically configure the local database for sync
Make online changes through SQL Data Services and propagate those changes to subscribed users once they connect
Enable scheduled and background synchronization of data changes through SQL Data Services and then on to other subscribed users
Backup and restore of database applications to the cloud

If you are interested in joining our early beta, please email DataLabs@Microsoft.com with “Huron beta” in the subject. For more information on Codename “Huron”, please visit http://www.sqlserviceslabs.com and click on Project Huron.

Screen Shots

Updated link and post title: 10/29/2008.

Tech Talk: Using Access with SQL Server Panel Discussion from TechEd 2008

Clint Covington — Fri, 20 Jun 2008 00:30:00 GMT

There is a good talk available called Are we there yet? Successfully navigating the bumpy road from Access to SQL Server.

Here is the description:

“Use SQL Server, not Access”, is advice commonly handed out when the Jet database engine outgrows its usefulness. However, that’s often easier said than done. Each database application is unique; some may have salvageable components, whereas others may need to be redesigned and rebuilt from scratch. In addition, there are substantial differences between the Jet and SQL Server database engines that can make a straight port unworkable in many situations. This panel discusses criteria for deciding whether to migrate data from Access to SQL Server, and for determining the optimal migration path once the decision is made. The panelists will share their real-world expertise to help you determine a successful strategy that best suits your business needs. With Mary Chipman, Armen Stein, Luke Chung, Paul Sheriff, and Stephen Forte.

There are other good talks available here…