Editing Microsoft Access (section)

===Migration to SQL Server===
{{Main|Upsizing (database)}}To scale Access applications to enterprise or web solutions, one possible technique involves migrating to [[Microsoft SQL Server]] or equivalent server database. A client–server design significantly reduces maintenance and increases security, availability, stability, and transaction logging.

Access 2000 through Access 2010 included a feature called the Upsizing [[Wizard (software)|Wizard]] that allowed users to upgrade their databases to Microsoft SQL Server, an ODBC client–server database. This feature was removed from Access 2013. An additional solution, the SQL Server Migration Assistant for Access (SSMA), continues to be available for free download from Microsoft.<ref>{{cite web|url=https://www.microsoft.com/en-us/download/details.aspx?id=54255|title=Microsoft SQL Server Migration Assistant 7.10 for Access|publisher=Microsoft.com|access-date=October 20, 2018}}</ref>

A variety of upgrading options are available.<ref>{{cite web|url=http://www.fmsinc.com/MicrosoftAccess/SQLServerUpsizing/how/index.htm|title=When and How to Upsize Microsoft Access Databases to SQL Server|access-date=March 13, 2016}}</ref> After migrating the data and queries to SQL Server, the Access database can be linked to the SQL database, subject to data type conversion limitations: 
*"Yes/No" types: In Microsoft Access there are three states for the Yes/No (True/False) data type: empty, no/false (0) and yes/true (−1). The corresponding SQL Server data type is binary, with only two states; the permissible values are 0 and 1. 
*Date/Time (Extended): SQL Server's smalldatetime format has precision of 1 minute, minimum date value is 1900-01-01, maximum date value is 2079-06-06; datetime format has precision of 10/3 milliseconds (rounded to increments of .000, .003, or .007 seconds), minimum date value is 1753-01-01, maximum date value is 9999-12-31; datetime2 format has precision of 100 nanoseconds, minimum date value is 0001-01-01, same maximum date value as datetime. Access's Date/Time and Date/Time Extended have higher precisions than smalldatetime and datetime and datetime2, and wider date range than SQL Server's smalldatetime and datetime formats.
Regardless, SQL Server is still the easiest migration. Retrieving data from linked tables is optimized to just the records needed, but this scenario may operate less efficiently than what would otherwise be optimal for SQL Server. For example, in instances where multi-table joins still require copying the whole table across the network.

In previous versions of Access, including Access 2010, databases can also be converted to Access Data Projects (ADP) which are tied directly to one SQL Server database. This feature was removed from Access 2013. ADP's support the ability to directly create and modify SQL Server objects such as tables, views, stored procedures, and SQL Server constraints. The views and stored procedures can significantly reduce the network traffic for multi-table joins. SQL Server supports temporary tables and links to other data sources beyond the single SQL Server database.

Finally, some Access databases are completely replaced by another technology such as ASP.NET or Java once the data is converted. However, any migration may dictate major effort since the Access SQL language is a more powerful superset of standard SQL. Further, Access application procedures, whether VBA and macros, are written at a relatively higher level versus the currently available alternatives that are both robust and comprehensive. The Access macro language, allowing an even higher level of abstraction than VBA, was significantly enhanced in Access 2010 and again in Access 2013.

In many cases, developers build direct web-to-data interfaces using ASP.NET, while keeping major business automation processes, administrative and reporting functions that do not need to be distributed to everyone in Access for information workers to maintain.

While all Access data can migrate to SQL Server directly, some queries cannot migrate successfully. In some situations, you may need to translate VBA functions and user defined functions into T–SQL or .NET functions / procedures. Crosstab queries can be migrated to SQL Server using the PIVOT command.