Power BI OLE DB or ODBC Error: The Real Fix for Every Variant
Five different messages get lumped under “OLE DB or ODBC error” — and each one has a different actual cause. Here’s the fix for each, not a generic “check your connection” answer.
The Direct Answer
“OLE DB or ODBC error” isn’t one bug — it’s an umbrella Power BI throws over five genuinely different failures. 0x80040E4E is usually a bad relationship or corrupted query step. 0x80040E1D is almost always a data-format mismatch, most often a date field. [Expression.Error] couldn’t fold means a transformation step can’t run on the source server. [DataFormat.Error] Unspecified error usually hides a bad row inside a merge or append. “The key didn’t match any rows” means a join is looking for a value that no longer exists in the source. Fix them differently — they are not the same problem.
Diagnose Your Exact Error
Pick the message you’re actually seeing — the fix is different for each one.
Your specific fix steps will appear here once you select an error above.
Power BI OLE DB or ODBC Error: Why It’s Really Five Different Problems
Power BI reuses this wrapper message for almost any failure that happens while a query is talking to a data source, regardless of what actually broke underneath. That’s why searching the exact phrase “OLE DB or ODBC error” turns up wildly different advice — half of it won’t apply to your case.
The part that actually matters is what comes after that phrase — the HRESULT code, or the bracketed error type. That’s your real diagnosis. Treat the two as completely separate errors, because they are.
0x80040E4E: Relationship and Query-Step Corruption
What’s actually happening
This is a generic OLE DB provider failure, which sounds unhelpful — but in practice it clusters around four specific causes, in order of how often they turn out to be it:
- A relationship has a blank or corrupted “related record.” Filter your data to find rows where the related-record lookup is blank, and fix or exclude them — several practitioners report this clearing the error immediately.
- A relationship is set to many-to-many when it should be many-to-one. Check cardinality on every relationship touching the failing table.
- The Power Query step chain is corrupted — usually from pasting M code directly into the Advanced Editor instead of building steps through the UI. Delete the table and manually rebuild the applied steps one at a time rather than re-pasting the old code.
- A network-layer mismatch — disable IPv6 on the machine running the refresh, and confirm TLS 1.2 is enforced. This is a real fix for some cases, but check it last — it resolves the error less often than the first three.
0x80040E1D: Data-Format Drift, Usually Dates
What’s actually happening
This code shows up when a source field’s format changes underneath a query that was built expecting the old format — the classic case is a date field shifting from 2019/9/9 to 2019-9-9, or a column name picking up a special character after a source-side update.
- Don’t just change the data type on the existing column — create a new, explicitly-typed column instead, and point downstream steps at the new one. Changing type in place on a drifted column frequently fails to fully resolve the mismatch.
- Check the source column name for special characters that weren’t there before — a source-side rename or schema update is a common trigger.
- If this started after a source system upgrade, check whether the source’s own date/locale settings changed — this is more common after ERP or CRM platform updates than people expect.
“We Couldn’t Fold the Expression to the Data Source”
What’s actually happening
Power BI normally pushes your Power Query transformations down to run on the source database itself — this is called query folding, and it’s what makes DirectQuery fast. When a step you’ve added can’t be translated into the source’s native query language, folding breaks. In Import mode this just slows things down; in DirectQuery mode, it fails outright, which is what you’re seeing.
- Right-click each applied step in order and check whether “View Native Query” is available. The first step where it grays out is exactly where folding broke — everything before it is fine.
- Move whatever transformation broke folding to after the point where you no longer need DirectQuery-level performance, or push it into a view on the source side instead of doing it in Power Query.
- This is especially common with Snowflake and other cloud warehouses in DirectQuery mode — certain M functions (custom columns with complex logic, some text functions) simply have no equivalent the source engine understands.
“DataFormat.Error: Unspecified Error”
What’s actually happening
This message is deliberately vague, and that’s the tell — it almost always means a bad row or a type mismatch is hiding inside a merge or append step, most commonly when you’re combining tables from two different source systems that don’t share exactly the same schema.
- Remove your merge or append steps one at a time, refreshing after each removal, until the error disappears — that tells you exactly which source table is introducing the conflict.
- Once isolated, check that table’s column types against the other side of the merge. A single column typed as text on one side and number on the other is enough to trigger this.
- If the conflict is in an append (stacking tables rather than joining them), check for a schema change in just one of the source tables — new column, renamed column, or a type change upstream.
“The Key Didn’t Match Any Rows in the Table”
What’s actually happening
This fires during a merge (join) step when a value in your key column no longer exists in the table you’re joining against. It’s rarely a Power BI problem — it’s almost always that the source data changed after the query was originally built.
- Confirm the merge kind actually matches what you intend — Inner Join will throw exactly this kind of failure where Left Outer Join would just return blanks instead.
- Check the key column on both sides for null or blank values — a join can’t resolve a blank against anything.
- If this started recently with no query changes on your end, assume the source data changed — a deleted record, a renamed ID, or a reloaded dimension table upstream.
The General Troubleshooting Order That Actually Works
Microsoft’s own refresh troubleshooting documentation is worth reading alongside this guide — it covers capacity-throttling and node-level errors that sit outside the five OLE DB/ODBC variants here, and the two guides complement each other rather than overlap.
✅ Work Through It In This Order
- Check refresh history before touching anything. The popup is a summary; refresh history in the Power BI service tells you which specific step and table actually failed.
- Reproduce it in Power BI Desktop first. If it only fails in the service but works in Desktop, the problem is gateway or credentials, not your query logic — a completely different fix path than everything above.
- Isolate by removing steps, not by guessing. Strip the query back toward the Source step and refresh after each removal. Whichever step reintroduces the error is your actual cause.
- Only then apply the error-specific fix from the sections above, once you know which of the five you’re actually dealing with.
⚠️ Don’t jump straight to reinstalling Power BI or clearing your entire credential cache. Both show up constantly as “fixes” in forum threads, and both occasionally work — by accident, because they reset something unrelated. Neither addresses any of the five root causes above, so if the underlying data or query problem is still there, the error comes back the next time the source changes.
Quick Reference Table
| Error | Most Common Cause | First Thing to Check |
|---|---|---|
0x80040E4E | Relationship or query-step corruption | Blank related-record values |
0x80040E1D | Date/data-format drift at the source | Rebuild the date column fresh |
| Couldn’t fold the expression | Unsupported transformation in DirectQuery | View Native Query per step |
| DataFormat.Error: Unspecified | Bad row hidden in a merge/append | Remove merge steps one at a time |
| Key didn’t match any rows | Source data changed since query was built | Check for nulls in the key column |
Frequently Asked Questions
What causes OLE DB or ODBC error: Exception from HRESULT 0x80040E4E in Power BI?
What causes OLE DB or ODBC error: Exception from HRESULT 0x80040E1D in Power BI?
What does “We couldn’t fold the expression to the data source” mean in Power BI?
What does “DataFormat.Error: Unspecified error” mean in Power BI?
What does “The key didn’t match any rows in the table” mean in Power BI?
Is OLE DB or ODBC error a Power BI bug or a data problem?
How This Guide Was Built
Root causes and fixes are drawn from Microsoft’s own official refresh-troubleshooting documentation, cross-referenced against real, dated threads on the Microsoft Fabric Community forum (2020–2026) where practitioners diagnosed and resolved each specific variant, plus independent 2025–2026 troubleshooting write-ups. Fixes are ranked by how frequently they’re reported to resolve the issue, not by which is technically simplest to write about.
Written and verified by A.J., Data Engineering Researcher · Ultimate Info Guide
