DM_GWPipeline_Gateway_MashupDataAccessError: We cannot convert the value null to type Text

[delaoda]

I have a semantic model connected to two different sources: a database in Azure and a  SAP WebI report. Since the latter requires a gateway, both connections use that gateway. Even though the other connection is to the cloud, this architecture is essential for the refresh to work in the first place.

Occasionally, the scheduled refresh fails with the error “We cannot convert to type text.” It’s important to note that it fails sometimes, not always. Even when I know the source data hasn’t changed between two consecutive refreshes, one of them might still fail.

In the Power Query for that dataset, I’ve taken special care with all data types, performing safe transformations whenever a string was involved. The proof is that the refresh works almost every time.

If I have a separate model for each connection, the scheduled refreshes never fail, which is the expected behavior. It is when the sources are mixed into the same model and the mashup comes into play, something happens that triggers the error, but it doesn’t provide any additional information about which specific query is causing the error.

Any ideas?

[arabalca · Accepted solution]

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!

[v-shchada-msft]

Hi @delaoda,

Checking if your issue has been resolved. If you need any further assistance, please let us know.

Thank you.

[v-shchada-msft]

Hi @delaoda,

Thank you for reaching out to the Microsoft Fabric Community Forum, and thanks to the @tayloramy and @arabalca  for sharing helpful insights.

Just checking in, were you able to resolve the issue using any of the suggestions provided? If not, please feel free to share an update, and we’ll be happy to assist further.

Your feedback will also help others facing similar challenges.
Thank you!

[Pegano]

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.

[tayloramy · Accepted solution]

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. 

[arabalca · Accepted solution]

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!