Migrating and Converting Microsoft Access to SQL Server

Transcription

1 WHITE PAPER Migrating and Converting Microsoft Access to SQL Server May ConvertU2 Technologies Pty Ltd. All rights reserved. ConvertU2, CU2, and 2SQL and 2SQL Inspector are either registered trademarks or trademarks of ConvertU2 Technologies Pty Ltd in Australia, the United States and other countries. Access and SQL Server are trademarks of Microsoft Corporation. White Paper Converting Microsoft Access to SQL Server Page 1

2 Introduction Have you ever thought my database is in Access, but I wish it were in Microsoft 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. 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. However, new methods have recently been developed and incorporated into ConvertU2 s product 2SQL 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 2SQL 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. White Paper Converting Microsoft Access to SQL Server Page 2

3 If you are not having issues or have no desire to beef up your application then it makes no 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. Below are some of the key issues which could influence a decision to migrate and convert to SQL Server: Azure Cloud Hosting Windows Azure is Microsoft s version of Windows built for cloud data centres, and SQL Azure is Microsoft s version of SQL Server built for the cloud. Unlike SQL Server, there is no equivalent version of Microsoft Access that is built for the cloud, so the only solution is to migrate the data component of an Access database to SQL Azure, and make the software in the Access database SQL Server compliant. The methodology to do this is exactly the same as SQL Server. Business Intelligence BI is non-existent for data in Microsoft Access tables. BI is a major component of SQL Server's core functionality. Data Repository 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 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. 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. White Paper Converting Microsoft Access to SQL Server Page 3

4 Maximum Database Size Access can theoretically support up to 2 GB of data. The file share-based JET database engine Access uses is not optimised 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. 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 optimised 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. 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. Software Re-engineering 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 White Paper Converting Microsoft Access to SQL Server Page 4

5 before more software development occurs. Migrating and converting to SQL Server first provides a wider ranging toolkit for any software reengineering. 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. 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 or 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).. Reference: Use the Upsizing Wizard, 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. 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 is discussed in an article from Tech Republic. Reference: Harkins, S. (July 31st, 2008). TechRepublic, 10+ tips for upsizing an Access database to SQL Server. 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. White Paper Converting Microsoft Access to SQL Server Page 5

6 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. Unless the application is completely converted, upsizing can be rendered useless. Microsoft Upsizing Wizard 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, Microsoft (February 2005) describes some of the limitations of the Microsoft Upsizing Wizard: Issue Nonstandard table or field names Description 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 Architectural issues Code not converted Items not upsized 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. 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. 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. The Upsizing Wizard does not convert any of the following objects: hidden objects, security settings, Format and InputMask properties, 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. Reference: Microsoft SSMA FAQ White Paper Converting Microsoft Access to SQL Server Page 6

7 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 Projects) 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 re-engineering 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 manually replaced with ADO in the VBA code. 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 The linked table solution is now recommended by Microsoft for upsizing to SQL Server. Access Services The development landscape for Microsoft Access is much more focused on SQL Server as a data repository with the advent of SharePoint 2013, Office 2013 and Office 365. The Access Services component of Sharepoint 2013 is much more versatile in its functionality than SharePoint 2010 and relies exclusively on the data being stored in a SQL Server 2012 or SQL Azure back end. For new databases, this means that Microsoft Access front ends can be developed to utilize the built in (Access) web page designers for data input, instead of Microsoft Access Forms, and Data Macros instead of VBA code to implement the programmatic component. For existing databases, neither the upsizing Wizard or the SSMA tools will prepare or upsize them for compliance to Access Services. This is because SharePoint relies on various schema rules/conditions of the SQL Server which are out of scope for the upsizing tools. White Paper Converting Microsoft Access to SQL Server Page 7

8 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. 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. 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 is simple. The good news is that one is less painful than the other. Upsizing Completely and Easily using 2SQL 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 optimised performance, data security and integrity, increased database size and number of concurrent users, professional level maintenance and backup procedures. In order to have a fully converted application the following must have occurred: 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. White Paper Converting Microsoft Access to SQL Server Page 8

9 The choice of making the schema of the SQL Server tables compliant to the Access Services Engine of SharePoint 2013 should be available as an option prior to conversion, even if the solution will not or cannot immediately utilise the advantages of the Access Services model. This is because locally based forms and reports are no longer part of the long term future of Microsoft Access. Choosing a solution compliant to Access Services provides less restrictions for new development. 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. Migrating and Converting with 2SQL 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. The length of the project and therefore the cost can be horrendous. ConvertU2's flagship technology called 2SQL automates over 95% of the effort to completely upsize 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 in the Genie (migrate and convert) mode by 2SQL, which will remedy every issue detected. Leveraging SharePoint s Access Services using 2SQL With 2SQL it is also possible convert and migrate Access Databases to be compliant with the Access Services engine of SharePoint, without compromising any of the existing functionality. This effectively provides the best of both worlds for future development, whereby the existing forms and reports can function as they always did using the 2SQL Methodology, and future development can be applied in the new landscape of Microsoft Access Web Pages. The 2SQL Technology and Methodology There is no other technology of such high automation available in the Access to SQL Server 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 Product Overview document explains the 2SQL Process and Methodology. 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 Northwind Access 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 section of the 2SQL User Guide. To find out more, or request a free evaluation of 2SQL, please visit White Paper Converting Microsoft Access to SQL Server Page 9