Fixing “ODBC Connection Failed” when importing SQL to Excel

The error “ODBC Connection Failed” appears in Microsoft Excel when an Open Database Connectivity driver fails to establish a communication handshake with an external database engine, such as Microsoft SQL Server, PostgreSQL, or Oracle. This error halts automated Power Query refreshes, breaks linked PivotTables, and prevents SQL query results from importing into the grid.

Because ODBC acts as a universal bridge between Excel and the database server, a connection failure points to a breakdown at one of four checkpoints: network routing, authentication, driver architecture mismatches (32-bit vs. 64-bit), or database security firewalls.

How to Fix “ODBC Connection Failed” in Excel

To resolve an ODBC connection failure, verify that your server name and port are reachable using Test-NetConnection in PowerShell. Confirm that your System DSN matches your Excel bitness (32-bit vs. 64-bit), select the modern ODBC Driver 18 for SQL Server, and update the connection string to include TrustServerCertificate=yes; if connecting over encrypted corporate networks.

---

Diagnostic Flowchart for ODBC Failures

When Excel returns an ODBC failure dialog, execute this troubleshooting sequence:

[ODBC Connection Failed]
         │
         ├──> Step 1: Network & Port Reachability (Ping / Test-NetConnection)
         │
         ├──> Step 2: Driver Bitness Check (32-bit Excel vs. 64-bit DSN)
         │
         ├──> Step 3: SSL / Encryption Certificate Settings (TrustServerCertificate)
         │
         └──> Step 4: Credential & Security Context (SQL vs. Windows Auth)

---

Step 1: Verify Network Reachability and Port Status

Before troubleshooting Excel or driver configurations, verify that your computer can reach the database server across your local network or corporate VPN.

1. Open Windows PowerShell.
2. Run the connection test command (replace with your server IP and SQL port, default is 1433): Test-NetConnection -ComputerName your-sql-server.domain.com -Port 1433
3. Evaluate the result:
   • TcpTestSucceeded : True — The server is reachable and accepting traffic on port 1433. The issue lies within driver configuration, encryption, or credentials.
   • TcpTestSucceeded : False — The server is unreachable. Common causes include an inactive VPN, local Windows Defender Firewall blocking outbound port 1433, or server-side firewall rules rejecting your client IP.

If your connection drops intermittently while working remotely, refer to Troubleshooting VPN-related connection drops during Power Query refreshes.. If the target machine actively rejects the handshake, proceed to Fixing “TCP Provider: No connection could be made because the target machine actively refused it.”.

---

Step 2: Resolve 32-bit vs. 64-bit Driver Bitness Conflicts

A common root cause of ODBC failures is a bitness mismatch between your Microsoft Office installation and the Windows ODBC Data Source Administrator.

• 64-bit Excel requires a 64-bit ODBC Driver configured in the 64-bit Data Source Administrator (odbcad32.exe located in C:\Windows\System32).
• 32-bit Excel requires a 32-bit ODBC Driver configured in the 32-bit Data Source Administrator (odbcad32.exe located in C:\Windows\SysWOW64).

Mismatch Trap:
You create a DSN in Windows "ODBC Data Sources" (defaulting to 64-bit),
but your company installed 32-bit Microsoft 325 Office.
Excel cannot see the 64-bit DSN -> Error: "ODBC Connection Failed"

Checking Your Excel Bitness

1. In Excel, go to File > Account.
2. Click About Excel.
3. The top line will state either 32-bit or 64-bit.
4. Open the matching ODBC administrator tool from the Windows Start menu (ODBC Data Sources (32-bit) or ODBC Data Sources (64-bit)).
5. Ensure your Data Source Name (DSN) is created under the System DSN tab, not the User DSN tab, so background services and Power Query can access it.

If your organization upgraded from legacy drivers and your scripts throw registration errors, consult Fixing “The provider ‘SQLNCLI11’ is not registered” on 64-bit systems..

---

Step 3: Fix SSL Certificate and Encryption Settings

Modern database drivers (such as ODBC Driver 18 for SQL Server) enable strict SSL/TLS encryption by default. If your database uses a self-signed corporate certificate or does not have encryption configured, the driver terminates the connection.

The connection string fails with the message:
[Microsoft][ODBC Driver 18 for SQL Server]SSL Provider: The certificate chain was issued by an untrusted authority.

The Solution: Update the Connection String

Add the following parameter to your connection string or DSN configuration:

TrustServerCertificate=yes;

If connecting via Excel’s Power Query Advanced options:

1. Navigate to Data > Get Data > From Other Sources > From ODBC.
2. Select your DSN, expand Advanced options.
3. In the Connection string (non-credential properties) box, enter: Driver={ODBC Driver 18 for SQL Server};Server=myServerAddress;Database=myDataBase;TrustServerCertificate=yes;

For detailed remediation of corporate SSL certificate chain errors, see Solving SSL Provider errors: “The certificate chain was issued by an untrusted authority.”.

---

Step 4: Verify Authentication Mode and Credentials

ODBC failures frequently occur when connection strings pass default Windows NT credentials to a server configured exclusively for SQL Server Authentication (or vice versa).

Windows Authentication String:
Trusted_Connection=Yes;

SQL Server Authentication String:
Trusted_Connection=No;Uid=myUsername;Pwd=myPassword;

To update stored credentials in Excel:

1. Go to Data > Get Data > Data Source Settings.
2. Select the database path or DSN showing the error.
3. Click Edit Permissions.
4. Under Credentials, click Edit.
5. Switch between Windows (using your Active Directory/domain credentials) and Database (entering your explicit SQL username and password).
6. Click Save, then click Refresh.

If authentication continues to fail despite entering valid credentials, consult Troubleshooting “Login failed for user”: Windows vs. SQL Authentication..

---

Step 5: Check Trust Center External Data Restrictions

If your ODBC configuration tests successfully inside the Windows ODBC Administrator tool but fails only when executed inside Excel, your Excel Trust Center settings may be blocking external data connections.

1. In Excel, go to File > Options > Trust Center.
2. Click Trust Center Settings, then select External Content.
3. Under Security settings for Data Connections, verify that it is set to Prompt user about Data Connections or Enable all Data Connections.
4. If set to “Disable all Data Connections”, Excel blocks the ODBC handshake automatically.

For step-by-step instructions on adjusting enterprise policy blocks, see Handling “The connection has been disabled” in Excel Trust Center settings..

If your connection succeeds but large database views terminate halfway through data extraction, your query may be hitting time limits. Extend the duration thresholds using Handling “Timeout Expired” errors in large-scale SQL views..