erratic connection Power BI Desktop --> Fabric SQL DW

Hi vanessa_fvg

The replies cover the VPN and SSMS tests. One thing they leave out is how the firewall treats the traffic. Learn says that if a firewall or proxy inspects at the application layer, the warehouse connection has to be handled as MSSQL/TDS traffic, not HTTPS, and that opening TCP 1433 alone may not be enough. It also says you can't allow the endpoint by its name alone, you need the Power BI and SQL service tags. A rule that only half fits can let some connections through and drop others, which would match "ONLY SOMETIMES".

I can't see your network, so I can't say that's the cause. Ask whoever runs the firewall to check its logs for the exact time of one failed attempt.

Hi vanessa_fvg​ ,

Could you review the suggestion provided above and let us know if you have any additional questions, we are happy to address. 

Thanks!!

Hi vanessa_fvg​,

Since the failed attempts do not appear in the Fabric Warehouse monitor, I would focus on connection establishment rather than query performance.

The error is occurring before Power BI gets far enough to submit the query to the Warehouse. That makes DNS resolution, TCP connectivity to the SQL endpoint, proxy/VPN behaviour, or the client connection path more likely than the size of the dataset.

I would test the exact same Fabric SQL endpoint from the affected machine using SSMS or sqlcmd at the moment Power BI fails. If SSMS also fails intermittently, that strongly points to the local/network path rather than Power BI itself.

I would also compare the behaviour on and off the corporate VPN or from another network if your policies allow it. Fabric SQL connectivity uses the SQL endpoint over TCP 1433, so intermittent filtering, proxying, or firewall inspection can cause exactly this kind of “server not found or not accessible” error before the request ever reaches Warehouse monitoring.

Another useful check is to capture Power BI Desktop traces from:

File → Options and settings → Options → Diagnostics → Enable tracing

Then reproduce one failed attempt and compare the timestamp with your Windows network/DNS logs and Fabric Capacity Metrics.

If the same endpoint works consistently from SSMS while Power BI alone fails, I would then clear the Power BI data source permissions and recreate the connection using the exact SQL endpoint copied from the Warehouse connection details.

So I would troubleshoot this in this order:

Power BI fails
→ test same endpoint immediately in SSMS/sqlcmd

both fail
→ investigate DNS/VPN/firewall/TCP 1433

SSMS works but Power BI fails
→ investigate Power BI credentials/client connection state

nothing appears in Warehouse monitoring
→ stay focused on connection establishment rather than query tuning

The fact that the model only has around 2,000 rows also supports that this is not a data-volume issue.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

Hi vanessa_fvg​ ,

Could you check the suggestion provided above and let us know if you have any additional queries?

Thanks!!

This looks more like an intermittent connectivity issue than a dataset size or query timeout problem, especially since the SQL Warehouse does not show the failed requests.

I would check the following:

1. Verify the SQL endpoint: Copy the server name directly from the Fabric Warehouse settings and ensure Power BI Desktop is using the correct SQL endpoint and database name.
2. Check network connectivity: Verify VPN, firewall, proxy, and outbound TCP port 1433 settings. If possible, test the connection from another network.
3. Test using SSMS: Connect to the same endpoint using SQL Server Management Studio. If the same error occurs intermittently, the issue is likely outside the Power BI query itself.
4. Clear cached credentials: In Power BI Desktop, go to File > Options and settings > Data source settings, clear the permissions for the endpoint, and reconnect.
5. Check the connection path: The Named Pipes Provider error can appear even when the underlying issue is network connectivity. Confirm that the SQL Server driver is using TCP/IP and that the client and driver are up to date.
6. Capture diagnostic logs: Use Power BI Desktop diagnostics to capture a failed connection attempt. Note the timestamp and correlation details, then compare them with Fabric monitoring and capacity metrics.
7. Check for capacity or service issues: Review Fabric capacity utilization and Microsoft Fabric service health around the failure times.

My first step would be to test the same endpoint in SSMS during a failure. Since the request does not appear in Warehouse monitoring, I would focus on connection establishment, DNS, firewall, and network routing before investigating query performance.

Hi vanessa_fvg​ 

Are there any patterns to when it is not accessible? Perhaps when you are connected to a company VPN or in office? Connecting to Fabric databases does require that port 1433 is open on your network, and a lot of companies block that.