Forum Discussion
FinOps Toolkit: DISP_E_TYPEMISMATCH when loading storage reports with data from March 2025
Description:
The Costs query of the loading the Cost Summary storage report fails with error "OLE DB or ODBC error: Type mismatch. (Exception from HRESULT: 0x80020005 (DISP_E_TYPEMISMATCH))." whenever March 2025 data is loaded alongside other months. The error appears at the Analysis Services load phase, not in Power Query Editor, which shows no errors.
Behaviour:
March 1, 2025 alone: loads successfully
March 2025 alone with full month: loads with no errors but shows normal row count
March 2025 combined with any other month: DISP_E_TYPEMISMATCH
April 2025 onwards combined with any other month from April onwards: works fine
February 2025: works fine
Brand new storage account and fresh template download: same error
Diagnostics already completed:
Parquet schema comparison across months via PyArrow: no mismatches
Value type comparison across months via Power Query: no mismatches
Row counts per month via ftk_Storage: normal for all months including March
Null column analysis across months: no differences
Deprecated: Perform Extra Query Optimizations set to true: did not resolve
All ftk_Storage column schemas when loaded: every column returns Any.Type
March parquet files contain all 31 days of data
Hypothesis from troubleshooting with AI: The boundary between the legacy export API and the Enhanced Cost Management Exports GA (released April 2025) may have introduced a subtle difference in parquet file encoding that PyArrow and Power Query both handle transparently but that Analysis Services handles differently when combining pre- and post-April data.
Template Version: Unknown but Downloaded today
Report: Cost Summary (storage version)
9 Replies
Hi XanB
It doesn’t really look like a simple bad-file problem in March itself. Based on the behavior you described, it seems more likely that the failure happens during the Analysis Services load, when Power BI tries to materialize a single consistent type across the combined data, rather than during Power Query ingestion. The biggest clue is that March 2025 loads fine on its own, other months load fine together, and the error only appears when March is combined with other months. Also, the same issue was opened today in the FinOps Toolkit GitHub repo and is still untriaged, so this may well be a genuine product edge case rather than something specific to your environment.
One thing that stands out in your diagnostics is that all ftk_Storage columns are ending up as Any.Type. That is often harmless inside Power Query, but it can become a problem later when the model engine has to enforce a single concrete type. In other words, Power Query may tolerate subtle differences that VertiPaq does not.
If I were troubleshooting this further, I would stop focusing on the parquet schema itself, since you already ruled out the obvious mismatches there, and instead force explicit types in the final Costs query before load. I’d start with the usual suspects like date/time fields, decimals, booleans, and nullable columns. If explicit typing does not resolve it immediately, the fastest next step would be to remove columns in halves until the combined March + non-March load succeeds, then narrow it down to the specific offending column and add defensive coercion such as try Number.From(_) otherwise null or try DateTime.From(_) otherwise null.
Your hypothesis about a transition between export implementations is also reasonable from a timing perspective. Microsoft discussed Enhanced Cost Management exports in spring 2025, and the FinOps Toolkit had release activity around that same period, so a March 2025 boundary effect is plausible. But at this stage I would still frame that as a working theory, not a confirmed root cause.
If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly
Thank you for your input, Rita. I will try forcing explicit data types then removing columns if that doesn't work. I'll follow up here when I have updates.
Hi v-aatheeque ,
I have yet to try this approach. I'm trying to use pre existing reports with data from this time frame and subscription, to see if there was a difference in how the exports are handled in PowerBI. I'm going through a couple iterations and will update here.Hi XanB
Just checking in were you able to test the approach with the existing reports and compare the export behavior?
Please let us know if you’ve observed any differences or if you need any further assistance.Hi
I wanted to check if you had a chance to complete your testing and observe any differences in the export behavior.
If you’re still working on it, no worries at all. Please feel free to share an update whenever convenient, and I’ll be happy to assist further if needed.
