A previous installation required a reboot of the machine for changes to take effect. To proceed, restart your computer then run Setup again.

Our records didn’t indicate ever trying to install this driver on these before, but something was clearly blocking the installation. Rebooting and attempting an install again resulted in the same error. To fix this error, Microsoft provides the Program Install and Uninstall troubleshooter. After downloading and executing, follow these steps.

The startup screen appears:

Click Next:

Click Uninstalling:

Note that this screenshot shows the driver as already installed as this is the list after the successful repair. This item did not appear in our list of installed programs when the original errors occurred.

Click Not Listed, then click Next:

Enter the Product code for this driver, which is {12DC69AF-787B-4D76-B69D-2716DACA79FB}. Be sure to include the curly braces. Click Next:

Note that this screenshot shows the name associated with the Product Code. During our initial use of the troubleshooter, the name shown was “Name not available”. Click “Yes, try uninstall”. If successful, the following screen will appear:

After clicking Close, try reinstalling the ODBC driver.

Good luck!

EDITED November 13 2020: Per the comments below, a reboot might be needed as a last step before reinstalling the ODBC driver.

The post FIXED: Installing Microsoft ODBC Driver 17 for SQL Server produces “A previous installation required a reboot of the machine for changes to take effect.” appeared first on Access DB Gurus.

Sign Up for SQL Azure Database

First, set up an Azure SQL database here.  Plans start from just a few dollars a month.  For most Access databases with a small number of users and simple reports, this is all that’s needed.  If you’re not sure, you’ll want to get the opinion of a Microsoft Access consultant who can evaluate your database.

The initial database setup includes an admin user that has access to all databases and server-level operations on this SQL instance.  You’ll probably want to create a separate database login and user that has privileges separate from the server admin user.

Migrate Data and Update App Table References

Second, migrating the database to Azure SQL can be done using a variety of methods.  One common method is to use the SQL Server Migration Assistant.  This tool automates many of the tasks associated with migrating an application such as replacing local tables with links to the Azure SQL tables, data type conversions, data integrity checking, default value checking, schema creation and a lot more.  If you don’t use this tool, you’ll need to create the SQL schema and import the data by some other means.

This tool will also require the Access Runtime Redistributable or Office 365 Access Runtime.  These applications may be incompatible with other versions of Office installed on the same machine, so we recommend installing the Migration Assistant or Runtime on a PC or virtual machine without Office already installed.

New ODBC Driver required

Third, the Microsoft ODBC Driver 17 for SQL Server will be required for the linked tables to connect to the Azure SQL database.  This is likely not already installed on a standard Windows PC.  Earlier versions such as version 13 can work as well.  The connection string for the linked tables will look something like this:

ODBC;Driver={ODBC Driver 13 for SQL Server};Server=tcp:azureservername.database.windows.net,1433;Database=databasename;Uid=username;Pwd=password;Encrypt=yes;TrustServerCertificate=no;Connection Timeout=30;

Azure SQL Firewall Setup

Because Azure SQL allows public connections, they could become easy targets for denial-of-service or brute force login attacks.  This concern is mitigated by the Azure SQL firewall that’s automatically activated with a new instance.  Firewall rules can be set for either the server level or the database level, and the rules can be set either in the Azure GUI or using stored procedures.

It may not be possible to know the IP addresses of all the Access application’s users due to dynamic IP updates, VPNs and working with varying remote locations.  Consider adding startup code to the Access database to identify the machine’s public IP address and execute either the server-level or database-level firewall rule stored procedure to add the current IP address to the allowed list.  The GRANT CONTROL permissions will be needed for the database-level users to make this update.

Performance Testing

Finally, you may find that some application operations are slower with an Azure SQL database.  This is partially due to ODBC queries that can’t be optimized.  Examples include SQL statements using VBA functions, subqueries, multiple table joins and joins between Azure SQL tables and local tables.  For these situations, consider rewriting the queries as SQL stored procedures or views then linking to those.

Conclusion

Azure SQL is a great way to make Access data accessible from Access applications remotely.  It’s an affordable solution that’s generally easy to set up.  Be sure to do plenty of performance testing on reports and complex queries as queries optimized for Jet databases could perform poorly in Azure SQL (or really any SQL Server) environment.

Need more help from a Microsoft Access Consultant? Give us a call!

The post Migrating Microsoft Access to Azure SQL appeared first on Access DB Gurus.