C O N V E R T I N G A C C E S S T O

S Q L S E R V E R – F U L L Y A N D C O M P L E T E L Y !

A W H I T E P A P E R F R O M C O N V E R T U 2 T E C H N O L O G I E S

A U T H O R – S T E P H E N K O O P

U P L O A D E D B Y P E T E R G R I F F I T H - < P G R I F F I T A T S E N E T . C O M . A U >

Beyond Upsizing

Introduction

Have you ever thought “my database is in Access, but I wish it were in SQL Server”? You would not be alone. Microsoft Access is the world’s most “popular” database solution. It is a very flexible and forgiving application development platform. Semi-skilled developers can create very useful applications for their businesses, teams, and departments. In the hands of a skilled developer very robust and complex database applications can be created. Because Access is so relatively easy to use and has so much power, companies of all sizes use Access to manage critical aspects of their business.

However, Access does have some significant built-in limitations and this white paper highlights several of them at the summary level.

There are millions of Access databases in use today and many of them are experiencing growing pains which could be alleviated by migrating to SQL Server. But Access and SQL Server are foreign to one another. There are several similarities, but even more differences between these two Microsoft products. They use different programming languages, have many different features, and have their own set of exclusive features, but most importantly they have very different database engines.

Benefits of SQL Server Platform

Microsoft provide tools which offer to “upsize” Access to SQL Server allowing you to keep the existing Access front end, store the data on the new SQL back end, and convert some simple queries. But these upsized “linked tables” solutions are hybrid applications and “incomplete” conversions which can never fully leverage all of the benefits of SQL Server.

Furthermore, performance can be compromised so severely that the converted application is dysfunctional. Of course, SQL Server itself can be at least ten times faster than Microsoft Access for the same instruction, but achieving this from Microsoft Access communicating with SQL Server requires server side processing. The hybrid solution(s) use client side processing, and this can actually result in the same instruction being ten times slower than it was originally.

Up to now, the only way to get all of the benefits of the SQL Server platform would be to either completely rewrite the application from scratch, or manually convert each conversion issue. This can range from being a very time consuming and very expensive process, to being impossible. The knowledge base, and magnitude of work required can make the project both cost and time prohibitive beyond any realistic consideration.

2SQL One Stop Shop

However, new methods have recently been developed which will fully and completely migrate and convert the entire application to SQL Server. This is sometimes known as “refactoring” the Access front end.

This paper will explore some of the reasons for wanting to convert Access to SQL Server, the limitations of incomplete hybrid conversions, the issues which must be addressed to achieve a complete conversion, and how new technology and methods can help you achieve a complete conversion to SQL Server in much less time and expense than the current methods.

Why convert to SQL Server?

Every discussion on the subject seems to start with the basic question of why convert. Either you are having issues and bumping into the innate limitations of Access or you are aware of specific benefits you can enjoy if you migrate to SQL Server.

If you are not having issues or have no “desire” to beef up your application then it does not make sense for you to convert.

If you are experiencing issues with your Access application first make sure they are not simply being caused by bad design and development problems.

Following are some of the key issues which could influence a decision to migrate and convert to SQL Server:-

Key Issues

Data Security Data resides on the desktop or network drive, as opposed to a centralised

(SQL) Server. This can pose a threat to data security due to access from a forbidden user, or conversely someone who needs to access the data, but cannot. Storing the data of an Access Application in SQL Server makes these issues much easier to manage and maintain.

Data Integrity/Backup and Maintenance Data integrity and recovery is not as robust on file-based databases using

Jet. Even with regular maintenance, the chance of failure is much higher than with SQL Server.

Access databases are easy to back up by simply copying the .mdb file which could also be a security concern but, if the Access database is open and the data is changing, it cannot be backed up while users are in it. This could be a major problem if the database is critical and used 24 /7. SQL Server has a robust set of administrative tools including Transaction Logs which can report who modified what data and Rollbacks which can undo changes.

Key Issues Contd.

Data and Software Security/Permission Levels Although Access databases can be password protected and encrypted, these

databases do not have the same level or versatility of security as SQL Server. If data and software security/permission levels are critical, a SQL Server solution is the better choice.

Maximum Database Size Access can support up to 2 GB of data – theoretically. The file share-based

Jet database engine Access uses is not optimized for large amounts of data. If there's a lot of data, SQL Server is the better choice. The general rule of thumb is the more data there is, the less robust Microsoft Access becomes.

Number of Concurrent Users Access databases can have problems with too many simultaneous users.

The number depends on how well the application was designed and what it was designed to do. SQL Server supports more users and more network traffic. There are also opportunities to improve performance by upgrading hardware memory and adding more CPUs with SQL Server. This option is not leveraged as much for file server databases like Access.

Key Issues Contd.

Performance Performance can be affected by a number of issues, but it is inherently affected

by the file share model of Access and the JET engine which provides processing on the client computer. The JET processing engine will not process Access data anywhere near as quickly as the SQL Server processing engine will process SQL Server data.

Network Bandwidth Access databases pass the whole table (or at least the index) across the network

when fulfilling queries. This may not be significant for small files, but performance suffers as the data and numbers of simultaneous users grow. An optimized application using SQL Server can significantly reduce the amount of data moving across the network because only the requested records are passed from the database to the application.

Data Collaboration Data that resides in Microsoft Access is not as easily shared with data from

other applications as SQL Server. In fact, the data may not be accessible at all due to residing on a local desktop that is not available from other desktops on the same local area network.

Key Issues Contd.

Web Enablement

Although an ASP.NET solution can use Microsoft Access as the data source, it is not as robust or reliable as using SQL Server for data input via web based forms. Several Access databases will also be candidates for migration to SQL Server so that the reports can be converted to (web enabled) SQL Server Reporting Services.

Software Development Environment

Both Access and SQL Server have software development features exclusive to themselves. However, adding the SQL Server toolset to a Microsoft Access application provides a lot more leverage. For example, asynchronous processing can be introduced by way of SQL Server agent jobs. This is just one of many features that become available.

Key Issues Contd.

Software Reengineering

Microsoft Access Applications often become convoluted and inefficient in their design. Complex applications push the limits of Microsoft Access to a level that severely compromises robustness and makes them cost prohibitive to develop and maintain. These factors bring about the need to reengineer the application before more software development occurs. Migrating and Converting to SQL Server first provides a wider ranging toolkit for any software reengineering.

Business Intelligence

BI is nonexistent for data in Microsoft Access tables. BI is a major component of SQL Server's core functionality.

Rewrite in VB.Net /ASP.Net?

Beyond the Microsoft Access Front End

There is often a desire to replace the Microsoft Front End completely with a VB.NET or ASP.NET solution. What is not realised or appreciated however, is the common ground in "converting" the front end first. When an Access front end is converted to SQL Server compliance, all the SQL Statements that reside in the Query, Form, Report and Module objects, will then reside in SQL Server as Views or Stored Procedures. This part is common ground to replacing the front end and is a very large component of such projects. Performing a conversion of the Access front end first to SQL Server compliance by way of linked ODBC and OLE objects provides an effective way to replace the front end in two manageable phases with very little overlap compared to one "do it all at once" project. It actually simplifies the entire process because troubleshooting during the testing phase can be broken down into conversion and reengineering categories.

Upsizing Microsoft Access to Microsoft SQL Server

According to Microsoft “Upsizing is the process of migrating some or all database objects from a Microsoft Access database (.mdb) to a new or existing Microsoft SQL Server database or new Microsoft Access project (.adp).”. Use the Upsizing Wizard,

http://office.microsoft.com/en-us/access/HP052730091033.aspx

There is no shortage of information on upsizing available, but there is no one stop shop that covers it all, at least until now. With just a little research on the web you can find articles, white papers, and tech notes on various Microsoft sites, articles in various web publications, books which have devoted chapters to the subject, and questions and answers on various discussion sites.

The objective is to alleviate some of the shortfalls of Access and / or to gain some of the benefits of the SQL Server platform. The result is a “hybrid” application with an Access .mdb front end which is “linked” to the SQL back end.

Upsizing Microsoft Access to Microsoft SQL Server

Microsoft provide tools which offer to “upsize” Access to SQL Server allowing you to keep the existing Access front end and store the data on the new SQL back end. But, these upsized “linked tables” solutions are hybrid applications and “incomplete” conversions which can never fully leverage all of the benefits of SQL Server. And as mentioned before, as complexity increases, so does the potential for the application to become dysfunctional.

“When the time comes to migrate your Access database to SQL Server, you could be in for a bumpy ride.” Upsizing will require a great deal of manual intervention to make it all work. A sampling of the issues are discussed in an article from Tech Republic Harkins, S. (July 31st, 2008). TechRepublic, 10+ tips for upsizing an Access database to SQL Server.

http://blogs.techrepublic.com.com/10things/?p=391

This manual work involved is just to get the upsizing to work. This is mostly for the table schema and data, but not the corresponding software that resides in the Access Queries, Forms, Reports, Macros and VBA Code Modules, which is where the conversion work is most often required.

To fully convert the Access application to SQL Server many manual conversion steps must be employed to pick up where the Microsoft tools left off.

Microsoft Upsizing Wizard

Unless the application is completely converted, upsizing can be rendered useless.

The Microsoft Upsizing Wizard is a tool Microsoft provides to “upsize” Access applications to SQL Server. The result of an upsizing of this kind is known as a “linked tables” solution.

The Microsoft White Paper, When to Migrate from Microsoft Access to SQL Server describes some of the limitations to the Microsoft Upsizing Wizard When to Migrate from Microsoft Access to Microsoft SQL Server - SQL Server Technical Article, Microsoft (February 2005)

Click to continue

Microsoft Upsizing Wizard contd

Issues

Nonstandard table or field names

Jet and SQL use different naming standards. The Upsizing Wizard can find some, but not all. Those that it does find and rename will not work in any existing code.

Differences in SQL

Access uses its own dialect of SQL that is different from the ANSI SQL supported by SQL Server. Many Jet-based queries cannot run on SQL Server without being rewritten.

Data type conversion issues

Access has its own standards for data types that are different in some cases from SQL Server. The Upsizing Wizard can make some choices for you in terms of converting data types, but changes require developer review.

Click to continue

Microsoft Upsizing Wizard contd

Architectural issues The Upsizing Wizard cannot rewrite your application to work correctly

with the SQL Server client/server model. Almost all Access applications are designed to work with the file share model of Jet. These designs do not lend themselves to the client/server model and can result in poor performance.

Code not converted The Upsizing Wizard does not convert any of the Visual Basic for

Applications code in your application. This can result in serious errors as parts of your application point to SQL Server while your code still points to an Access (Jet) database.

Items not upsized The Upsizing Wizard does not convert any of the following objects:

hidden objects, security settings, Format and InputMaskproperties, Table or Field caption properties, table lookup fields, crosstab queries, action queries that use parameters, many query properties, macros, and module code.

SQL Server Migration Assistant for Access (SSMA)

SSMA for Access is the next generation upsizing tool from Microsoft. According to information on their web site “SSMA for Access offers a richer set of features, such as network scanning, conversion assessment reports, and more. SSMA for Access also fixes many issues currently not handled correctly by the Office Upsizing Wizard”. Microsoft SSMA FAQ http://www.microsoft.com/sqlserver/2005/en/us/migration-access-learning.aspx

Although SSMA has more functionality than the upsizing wizard, its potential to deliver a complete solution remains indirectly proportional to the software complexity of the Access database. For example, It will convert simple Access queries to SQL Server Views, but as soon as such queries reach a certain level of complexity, the SSMA tool will be unable to cope with it. It also does not encompass required changes to the VBA code, and this is almost always a major part of any Access to SQL conversion project.

ADP (Access Data Project)

An Access Data Project is Microsoft’s solution to the elimination of JET as part of the upsized solution. Access Data Projects use ADO/OLE based connections to SQL Server exclusively.

The upsizing wizard will allow the choice of a linked table, or an ADP solution. However, using the wizard to convert to an ADP has the following restrictions:- It is nowhere near as functional as SSMA for Access when converting the Access queries to

SQL Server Views or Stored Procedures. The recordsource of bound forms will use an ADO/OLE Recordset. Although this has many

performance benefits, these forms may require various design changes to remain functional. DAO of any kind is not supported, and there is not always a direct equivalent in ADO, or the

Access Engine. This means that the application will require reengineering as opposed to converting, in these areas.

There are known issues with the ADP event handler. Control can be passed back to the Access front end before SQL Server instructions have completed.

DAO must be replaced with ADO in the VBA code manually. As of Access 2007,Access Data Projects are no longer part of the Microsoft Access

development plan. They are supported as is but do not encompass the entire tool set of Access 2007. The linked table solution is now recommended by Microsoft for upsizing to SQL Server.

Why Upsizing falls short

The results of an upsizing project using any of these methods could be a fully functioning Access database with a SQL Server back end data container, but this likelihood decreases as software complexity increases. What this means is that the more there are of Access Queries, Forms, Reports, Macros, and VBA Modules, the less likelihood there is of a fully functional application after upsizing. Only databases of relatively simple complexity are candidates for the free upsizing tools from Microsoft.

Although all table data is stored in SQL Server, Access still uses JET to run queries, store object definitions, manage temporary tables, and hold security settings. Only the table schema and data is migrated reliably. Most importantly, the data processing engine is still JET, not the SQL database engine.

Contd. Next slide

Why Upsizing falls short

A knowledgeable developer can manually convert or programmatically convert additional objects that the Wizard or SSMA do not attempt to upsize. This will make the overall application somewhat more robust, but still an Access application on the front end running JET with a SQL backend running its engine. “The interaction of these two engines can sometimes yield results that are inferior to those obtained by using only the Jet database engine with native Office Access tables.” When to Migrate from Microsoft Access to Microsoft SQL Server - SQL Server Technical Article, Microsoft (February 2005)

The Microsoft Upsizing Wizard, SSMA, or any of the commercial upsizing tools available only provide a fraction of these critical changes to the Access application, thereby providing an “incomplete conversion”.

To have an application enjoy all of the benefits of the SQL Server platform requires a complete conversion or a complete rewrite of the application. Neither of these options are simple. The good news is that one is less painful than the other.

Upsizing Fully and Completely

A complete upsizing, or conversion, is going to result in an application that takes full advantage of the functionality and power of the SQL Server platform including optimized performance, data security and integrity, increased database size and number of concurrent users, professional level maintenance and back-up procedures.

In order to have a fully converted application the following must have occurred:

Upsizing Fully and Completely

Fields and Tables are created in the new SQL backend and all data is migrated.

Table field types, indexes, default values, validation rules and relationship constraints are all converted to their SQL Server equivalents.

Every SQL expression in the Queries, Forms, Reports and Modules are converted from JET Syntax to T-SQL Syntax.

The DAO connection objects in the VBA code are replaced with ADO/OLE connection objects.

The Forms and Reports adhere to ODBC refresh interval requirements. In built Access Engine and VBA commands that invoke client side

processing are replaced with an equivalent server side processing method.

If an application is converted to this extent the Access application is now a "SQL Server Compliant" application. The Access Jet database engine will have been reduced to a connection object wherever possible, and all “processing” will take place on the backend SQL Server database.

2SQL Migration and Conversion

Is it even possible to completely convert an existing Access front end to achieve a complete upsizing? We suggest it is possible, but not without a complete understanding of the conversion issues involved and not without a lot of work if it were all to be attempted manually.

ConvertU2's flagship technology called 2SQL is at least a 90% automated solution to fully and completely upsizing a Microsoft Access database to SQL Server. It is available to the public domain via a registration and download process that lets you scan your databases for free, using the 2SQL Detective to identify conversion and migration issues . Upon purchase of an official 2SQL Software Licence, these databases can then be reprocessed Genie (migrate and convert) mode by 2SQL, which will remedy every issue detected.

2SQL Migration and Conversion

There is no other technology of such high automation available in the marketplace today.

The 2SQL User Guide explains how to use 2SQL in an Access to SQL Server upsizing project, and how to continue on with the manual cleanup work for the small percentage of issues that 2SQL did not automatically remedy.

The 2SQL Technical Reference Guide explains all the migration and conversion issues and also the solution that 2SQL implements to conquer them.

For the technical enthusiasts wishing to evaluate a fully functional version of 2SQL, ConvertU2 allow this to occur whenever Microsoft's NorthwindAccess database is selected for processing. The entire process from start to finish is also documented in ConvertU2's Applying the 2SQL Technology and Methodology to Northwind paper.

To find out more, or request a free evaluation of 2SQL, please visit www.convertu2.com

ConvertU2 Technologies

PO Box 2308

Kent Town

South Australia 5071

+61(0) 405 149 777

www.convertu2.com

ABN 16 123 065 556

151 Coolidge Avenue Suite 713 Watertown, MA 02472 USA + 1 617 335-6679 jtodd@convertu2.com