Forum Discussion
DM_GWPipeline_Gateway_MashupDataAccessError: We cannot convert the value null to type Text
Hi delaoda ,
Before spending more time debugging the model, it is worth stepping back and asking whether the problem lies in the model itself or in the architecture.
When a semantic model pulls directly from two different sources, especially when one of them goes through an on-premises gateway, you are exposing the model to all the variability those sources carry: changing schemas, timeouts, inconsistent type inference during mashup evaluation. The result is exactly what you are describing: an intermittent error that does not always appear and is hard to reproduce or diagnose.
The solution applied in modern data architectures is the Medallion pattern. Instead of having the model consume the sources directly, an ingestion process reads each source separately, transforms and consolidates the data into tables in a Gold layer within a Lakehouse. The semantic model then points exclusively to those tables.
With this approach, the model is completely decoupled from the sources. Type conversion issues, gateway dependencies, or any inconsistency coming from SAP WebI are handled once in the transformation layer, not on every scheduled refresh. You also gain independent control over the ingestion frequency of each source.
This is the same principle that has been applied in data engineering for years: separating the responsibility of acquiring the data from the responsibility of consuming it. Applying that principle to the semantic model eliminates at the root the class of errors you are seeing.
*If you find this helpful please give it a 👍, and if it answered your question please mark it as a solution ✅. This helps the community and motivates me to keep contributing. Thank you!
Hi delaoda,
Intermittent errors are always the worst to troubleshoot.
Seeing as both your connections work independently, what I would recommend is keeping them seperate.
Are you licenses for Fabric, or just Power BI?
If you're licensed for Fabric, you can copy the PowerQuery code into a dataflow gen 2 and store the data in a lakehouse, you can then either use a third dataflow to combine them if you need them in one table, or you can keep them as seperate tables and pull them directly into your report. That would likely be the easiest way to achieve this.arabalca brought up medallion architecture, which is valuable, but it's not a one size fits all solution. So often do we see people make medallion layers that exist only to follow the bronze silver gold pattern, which I'm not sure is required here.
If you're not licensed for Fabric, then you're in a bit of a pickle.
How is the data joined in your report? Are they kept as seperate tables? If so, you could make two "dummy" reports that each pull in the data from one source, and then in your real report connect to those semantic models.
Hi delaoda,
The architecture answers above are valid long-term, but before committing to that refactor it might be worth understanding the failure pattern first.
A few questions that could help narrow it down:
- Does the failure always happen at the same time of day, or is it truly random?
- Do you see it more often when other datasets in the same workspace are refreshing simultaneously?
- Is the gateway under load from other connections when it fails?
The reason I ask: intermittent DM_GWPipeline_Gateway_MashupDataAccessError with null conversion is often a race condition in the mashup evaluation — the gateway pulls both sources and one of them returns an empty intermediate result before the join, which then fails the type cast. It's not about the data itself but about timing.
If you can see the exact timestamps of the failed vs. successful runs and correlate them with gateway activity, that often points directly at the cause without needing an architecture change.
I built MetricSign specifically for this kind of diagnostic — it tracks every refresh run with timestamps, error codes, and duration so you can spot these patterns. Happy to help you look at it if you want a second pair of eyes on the failure history.