How Do You Fix the OLE DB or ODBC Error in Power BI?

How Do You Fix the OLE DB or ODBC Error in Power BI?

A refresh fails, you open the error, and Power BI tells you there has been an OLE DB or ODBC error.

Then it stops. No cause, no setting to change, no link to a help page. Search the phrase and you find hundreds of threads, each a different problem under the same headline, a fair number ending with somebody reinstalling Power BI Desktop out of desperation.

There is a reason for that, and knowing it changes how you troubleshoot. This message is not a fault. It is an envelope, and the thing you need to fix is inside it.

How Do You Fix the OLE DB or ODBC Error in Power BI? The Short Answer

You do not fix the OLE DB or ODBC error. You find out what it is wrapping, and you fix that.

The phrase is a generic prefix the modeling engine puts in front of whatever a database-style connector handed back. The connector's own message follows, and that message is the error. Everything useful lives after the colon.

So the first move is never a settings change. It is to open the refresh history, expand the failed attempt, and read the full text rather than the summary line.

The fault underneath is almost always one of five things: credentials that expired or were never valid, a gateway that is offline or has no entry for the data source, privacy levels refusing to combine two sources, a driver that is missing or the wrong architecture on the machine doing the work, or a query that ran out of time.

Each of those has a documented fix. The wrapper does not, which is why searching for the wrapper gets you nowhere.

Refreshes failing quietly is one kind of invisible problem. Pages that never get found is another. Get a free audit and see what yours looks like.

Why This Error Message Tells You Almost Nothing

It is worth being precise about how little official standing this message has, because it explains the state of the search results.

Microsoft Does Not Document It for Power BI

Search Microsoft Learn for the exact phrase and you will not find a Power BI page about it. It is absent from the refresh troubleshooting article, absent from the gateway troubleshooting article, and absent from both Power Query error-handling pages.

Where it does appear in Microsoft's documentation is Analysis Services, in an article about cube processing failures, which names the error as OLE DB error: OLE DB or ODBC error: Operation canceled; HY008.

That is a clue rather than trivia. The string comes from the tabular engine underneath Power BI, not from the Power BI interface, which is why Power BI's own troubleshooting pages have nothing to say about it.

The Brackets Are the Part That Matters

Microsoft does document the anatomy of a Power Query error, and that is what lets you read these messages properly. It describes an error reason as "the first section before the colon," an error message as "the section directly after the reason," and an error detail as "the section directly after the Details: string."

So in a message shaped like OLE DB or ODBC error: [DataSource.Error] ..., the bracketed token is the reason and the text after it was passed up by the connector or driver. That trailing text is the diagnosis.

Worth knowing: Microsoft publishes no catalog of these reason codes, so any article offering you an official list of DataSource.Error meanings has invented it.

Even the Error Codes Mislead

The codes are not reliable signposts either, and Microsoft says so about its own. In the Analysis Services article it notes that 08S01 maps to DB_E_CANNOTCONNECT and that this is "a misnomer: it may mean the system can't connect, or that it was disconnected or canceled by the provider or server." When the message ends in 0x80004005, Microsoft's error-code specification defines that value as E_FAIL, documented simply as "Unspecified error." The layer that raised it had nothing more specific to offer.

How to Find the Real Error, Step by Step

1. Open the semantic model's refresh history. Microsoft's documented route is to select Refresh in the ribbon on the model's details page, then Refresh history.
2. Find the failed attempt and expand it. Microsoft's docs use the label Show in refresh history and Show details in the gateway guidance, so expect either.
3. Read the whole message, not the first line. Microsoft states that within Show details "the error message that was received from the data source is displayed." That sentence is the entire point of this exercise.
4. Copy the text after the bracketed reason and search that instead of the wrapper. A login failure, a certificate warning and a timeout all arrive under one identical headline.
5. If an on-premises gateway is involved, collect its logs: open the gateway app, select Diagnostics, then Export logs, which writes a zip file to an ODGLogs folder on the desktop.
6. Confirm whether the failure reproduces in Power BI Desktop. If it refreshes cleanly on your machine and fails in the service, the problem is environmental rather than in the query.

That last step is the highest-yield check in the list, and the next section explains why.

Wondering which of your pages are quietly failing to earn traffic? Request a free audit.

The Causes Microsoft Actually Documents

Credentials That Expired or Changed

Microsoft's refresh troubleshooting article carries a section headed "Data refresh failure because of password change or expired credentials," and for forbidden-resource errors says the cause "can occur because of expired cached credentials."

There is a constraint that catches people out. Microsoft documents that each user "can only have one set of credentials per data source" across every semantic model they own, and that each model has exactly one owner. If you are not the owner, you cannot change the credentials until you take the model over.

Watch for the OAuth variant, which masquerades as a credentials problem and is really a clock problem. Microsoft documents that the token "expires in approximately one hour" while the service "waits for up to two hours when loading data," so a long refresh "can fail with a credentials error" on credentials that were perfectly good.

A Gateway That Is Offline or Missing the Source

If the source is not reachable directly from the cloud, Microsoft is explicit that "you must configure a gateway connection for this semantic model before you can enable a refresh schedule or perform an on-demand data refresh."

Its own first-line check is blunt: "Verify the report has a gateway selected. If there's no gateway selected, the data source might have changed or might be missing." Two further documented constraints matter: a model can use only one gateway connection, so a query spanning two gateways cannot work, and only gateway admins can add data sources to a gateway.

If you hit GatewayNotReachable while setting credentials, Microsoft attributes it to an outdated gateway, and notes that only the last six gateway versions are supported.

Privacy Levels Refusing to Combine Sources

This is the best-documented cause in the set, and the likeliest explanation of a refresh that works on your desktop and fails in the service.

Microsoft documents an error reading "Information is needed in order to combine data," and describes the trap exactly: the desktop refresh works because the Always ignore privacy level settings option is on, that option does not exist in the service, and the published model throws a firewall error instead. The documented fix is to set real privacy levels in both the global and current-file options, republish, then set the credentials to Organizational in the service.

Why it blocks is worth understanding. Microsoft defines a source marked Private as one whose data "can't fold into other data sources, including other private data sources," while an Organizational source "can fold into private and other organizational data sources" but not into public ones. Resist switching the override on in Desktop and moving along: Microsoft warns that ignoring privacy levels "could expose sensitive or confidential data to an unauthorized person."

A Missing or Wrong-Architecture Driver

When a gateway is involved, the query does not run where you built it. Microsoft describes the gateway as a bridge "evaluating query expressions on the gateway machine," and adds that transformations use "the version that's installed on the gateway machine."

That produces the most quotable cause in Microsoft's planning guidance: "Missing or mismatched components between creator machines and data gateways is a common reason for data refresh failures of published content." The instruction that follows is to install the same drivers, connectors and providers on the gateway as the report authors have.

Architecture is where it gets specific. Microsoft's paginated-reports guidance states that the gateway requires "the 64-bit version" of a driver and that file DSNs are unsupported, so you should "create a 64-bit System DSN on the gateway computer." For personal mode, the docs require "a 64-bit version of the data providers to be installed on the same computer" as the gateway.

One caveat: those statements sit on the paginated-reports and personal-mode pages rather than in general import-refresh documentation, so treat the architecture rule as well evidenced rather than as one official sentence. The practical version is simpler than it was, because Microsoft now states plainly that "the 32-bit version of Power BI Desktop is no longer supported."

A Query That Ran Out of Time

Timeouts arrive under the same wrapper and read as connection failures, because the connection was fine until it was not.

The number to know is the command timeout. Microsoft documents a default CommandTimeout of ten minutes for both the SQL connector and ODBC connections, and recommends you "increase the CommandTimeout value in your M code if long-running source queries are contributing to refresh failures."

Above that sit the refresh duration limits: Microsoft currently documents a two-hour ceiling on shared capacity rising to five hours on Premium, with the XMLA endpoint able to bypass the five-hour figure. Those are capacity-dependent and have been revised before, so check the current ones rather than planning around a number in an article.

There is also a documented gateway concurrency limit of 30, with its own error. That one looks like a connection problem and is really a queueing one.

Limitations: What You Cannot Fix From the Power BI Side

Some of these failures are not yours to resolve, and recognizing that early saves a wasted afternoon.

If the message is a network or instance error from SQL Server, the fix is on the server and the network. Microsoft's summary is that such errors "typically appear when the SQL Server instance isn't running, the server or instance name is incorrect, network protocols aren't configured correctly, or firewalls block required ports."

Gateway connectivity has the same character. Microsoft's checklist asks whether the required addresses and ports are allowed through your firewall and proxy, notes that "some proxies restrict traffic to only ports 80 and 443" while relay traffic by default uses others, and points to a built-in network ports test. No amount of query rewriting answers an infrastructure question.

One limitation is purely about time. Microsoft has published a plan to move several connectors off embedded ODBC drivers to Apache Arrow Database Connectivity, with driver removal described in planned phases that are all marked subject to rollout readiness. Note the scope limit in Microsoft's own words: the change "doesn't change behavior for the ODBC connector when you use a separately installed ODBC driver." If you installed the driver yourself, you are outside it.

Spending real effort on reports nobody outside the business ever sees? Start with a free audit.

This Error vs the Other Refresh Failures

It helps to know which failures are genuinely generic and which are specific, because the two deserve different amounts of searching.

The OLE DB or ODBC wrapper is the most generic. It carries almost no information alone, demands that you read the payload, and is the only common refresh error Microsoft does not document for Power BI at all.

Memory and capacity errors are the opposite. Strings like "Query memory limit exceeded" and "Capacity level limit exceeded" are documented, specific, and tell you what to do, which is usually to shrink the model or move it to a different capacity.

Gateway errors sit in between: messages such as "Your data gateway is offline or couldn't be reached" are documented with their own headings and checklists, so they are worth searching verbatim. And a few are diagnostic the moment you see them. "Information is needed in order to combine data" means privacy levels, every time. "The following system error occurred: Type Mismatch" is a data problem rather than a connection problem. Take those at face value.

The habit to build is simple: if the error names something, search that name. If it only says OLE DB or ODBC error, the name you want is further down the message.

Want the same clarity about where your search traffic actually comes from? Get a free audit.

Final Thoughts

The OLE DB or ODBC error is the least informative message in Power BI, and it is informative about one thing only: something below the modeling engine refused a request.

Treat it as a label on a box rather than a diagnosis. Open the refresh history, expand the failure, read past the colon, and work on the sentence the connector actually sent. Nine times in ten that sentence names a credential, a gateway, a privacy level, a driver or a clock.

The deeper lesson is about where the query runs. Once a gateway is involved your desktop is no longer the environment that matters, and a refresh that works locally and fails when published is telling you about a machine you have not looked at yet.

If the connector underneath yours is a self-installed ODBC driver, our walkthrough of connecting NetSuite to Power BI covers that route end to end, including the data-source configuration step where most of these errors are born.

Fix the thing inside the envelope, keep the gateway's components matched to your authors' machines, and this error stops being a mystery and becomes a pointer.