gateways
2155 Topics
Schedule Refresh failed (Premium_ASWL_Error)
Starting last week, I have had schedule refreshes failing with this message: Data source error{"error":{"code":"Premium_ASWL_Error","pbi.error":{"code":"Premium_ASWL_Error","parameters":{},"details":[{"code":"Premium_ASWL_Error_Details_Label","detail":{"type":1,"value":"Cloud data source refresh is not allowed in gateway setting."}}],"exceptionCulprit":1}}} Table: MyTableName. The table(s) the error is relating to come from Sharepoint folders. Currently it is happening in 2 different reports. The schedule refresh had been working fine previously for months. I did not make any change to the dataset recently.26KViews0likes5Comments
Power BI Desktop Snowflake Refresh Fails: “Cannot Convert Null to Text” While Service Still Works
Hi all, I’m seeing a sudden Power BI Desktop refresh failure with Snowflake-backed Power Query tables. Has anyone else seen this with recent Power BI Desktop / Snowflake connector builds? Is there a known regression or recommended workaround? Power BI Desktop version: 2.155.756.0 Install type: Microsoft Store app Connector: native Snowflake connector Pattern: Snowflake queries fail in Desktop, but the same SQL runs successfully in Snowflake and the dataset/report still refreshes in Power BI Service. Representative M pattern: let Source = Value.NativeQuery( Snowflake.Databases( "<snowflake_account>", "<warehouse>", [Implementation="2.0"] ){[Name="<database>"]}[Data], "<native SQL query against a Snowflake view>", null, [EnableFolding=true] ) in Source Desktop refresh error: cannot convert the value null to type Text. Things already tried: Restarted machine Uninstalled/reinstalled Power BI Desktop Cleared/re-authenticated data source credentials Removed [Implementation="2.0"] Removed [EnableFolding=true] Replaced select * with explicit column casts Tested multiple Snowflake queries/tables4.9KViews17likes15Comments
Gateway 3000.322.4 (June 2026): refreshes failing with DataSourceAccessError / InvalidCastException
Hi, Ever since the June 2026 update (gateway standard mode, v3000.322.4), our dataset refreshes keep failing intermittently with DM_GWPipeline_Gateway_DataSourceAccessError. It's an on-prem SQL source, import mode, West Europe. Smaller queries are fine, but the big/long-running ones fail fairly often. It worked fine on the previous build. Digging into the gateway logs, the real error isn't the data source — it's an internal cast exception: InvalidCastException: Unable to cast object of type '...Communication.OperationExecutingAsynchronouslyResult' to type '...Communication.ExecuteQueryResult' After that it cascades into "The spooled operation id ... does not exist. Evict code: -1", "The data reader has been closed", "The command has been canceled", and the refresh dies. Looks like an async query result is being cast to the synchronous result type and blowing up. Things I've already ruled out: renewed the credentials (auth succeeds in the logs, the connection opens fine and it only fails mid-stream), scaled the host to 8 vCores / 12 GB (no change), and the port test passes 33/33. So it's not creds, resources or network. Is this a known regression in 3000.322.4? And if so, is there a fixed build out, or a build you'd recommend rolling back to in the meantime? Happy to share full logs privately. Thanks295Views4likes1Comment
Potential Microsoft Fabric Copy Job Issue – Incremental Column Detection with Snowflake
While configuring an Incremental Column in a Microsoft Fabric Copy Job against a large Snowflake table/view, I noticed behavior that may be worth investigating by the Fabric engineering team. Observation Instead of appearing to retrieve the column metadata directly (similar to a SHOW COLUMNS or equivalent metadata query), the Copy Job seems to execute a query using something similar to: SELECT ... LIMIT 10 On large or complex Snowflake views, this can take significantly longer than expected because the view may still need to be resolved before returning even a small number of rows. Additionally, I observed that the request appears to hit a web request timeout of approximately 3.3 minutes while trying to detect the incremental column. As a result, the Incremental Column selector remains in a loading state and never completes. Questions for the Microsoft Fabric Team Is the Incremental Column detection intentionally based on sampling data (LIMIT 10) rather than retrieving metadata? Would using Snowflake metadata APIs or SHOW COLUMNS provide a faster and more reliable experience? Can the timeout for metadata discovery be increased or made configurable for large enterprise workloads? Is this a known issue or something already planned for optimization? If this behavior is expected, understanding the design would be very helpful. If not, it may be an opportunity to improve the user experience for customers working with large Snowflake datasets. Has anyone else experienced similar behavior with Fabric Copy Jobs and Snowflake?83Views0likes1Comment
Add "One-Click Rollback" button after buggy updates for Gateway & Power BI Desktop
Problem: Every 2-3 months Microsoft releases a new Gateway or Power BI Desktop update. But sometimes the update breaks critical things. Example: Gateway version 3000.322.4 June 2026 update is causing intermittent refresh failures with DM_GWPipeline_Gateway_DataSourceAccessError for large datasets. Right now if an update breaks production, we have to waste 4-5 hours finding the old installer, uninstalling, and reinstalling manually. Impact: 1. Production reports go down 2. Business users can't get data 3. IT admins waste hours on rollback 4. No official way to go back to stable version Suggested Solution: Add a "Rollback to Previous Stable Version" button inside the Fabric Admin Portal and Power BI Desktop. When a new update is installed, keep the last 2 versions saved. If something breaks, 1 click and it reverts back. Just like Windows "Uninstall Updates" feature. This will save hours for every company using Fabric and Gateway.48Views0likes0CommentsIssue: Oracle Cloud Connection created without centralized On-Premesis Gateway and can't delete it.
Hello, this problem recently happened on Friday, and I think I am up a creek without a paddle. I have a Power BI Pro license using the On-Premises Gateway (Personal mode) for refreshes. The company does not have a standard On-Premises Gateway installed and configured. We use Oracle database for alot of our backend data. I just recently upgraded to the June 2026 update of Power BI Desktop with all preview features enabled. All of my reports that use Oracle are connected with the native Oracle database connector that utilize the personal gateway. Somehow, a Cloud version of the Oracle connector got created on the service, and nothing will connect because we do not have a standard gateway. I have tried deleting the Oracle cloud connections and trying to rebind it with a new file, but, it just keeps coming back. This article states if this happens, this is irreversible: https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-connect-oracle-database. However, I don't understand how it could be created without an installed centralized gateway? How can I fix this? I'm open to extreme steps at this point, minus getting the centralized On-Premises installed, because that is not going to happen this year. If I have to get our vendor to reset my entire workspace and license to start from scratch, I'm willing to do that, assuming it will actually work. Any suggestions would be helpful. I really need to be able to use the native Oracle connector with the personal gateway.284Views0likes1CommentPowerBI--Arm compatibility
Hello, My organization has built in pathways for connecting PowerBI to Access for our database. The issue is that I recently got a new computer with a snapdragon-Arm processor, and Access and PowerBI no longer are able to connect. After attempting just about every way under the sun to fix this, I feel like this is probably a bug microsoft needs to patch, but I'm really hoping that someone else who has had this issue might have a way to solve it. The exact error code I'm getting in powerbi is 0xC000026F. Excel power query can connect to access just fine, so it's not office itself, it's specifically power bi and it's capatability with the other office apps. This is where chatgpt and I got to with determining the underlying issue: Power BI runs x64 It runs inside a Windows ARM64 emulation layer It tries to load Access via Office Click-to-Run (ARM64 + App-V subsystem) That crosses into: ARM64 Office virtualization (AppvIsvSubsystems64_arm64x.dll) x64 Mashup container That bridge is what is crashing immediately Excel works because: It uses a more direct Office-hosted path Not the same Mashup container sandbox Power BI uses Anyone have the same issue?161Views0likes0Comments
Power BI Desktop connects to Snowflake using RSA Key, but Power BI Service returns Error
I’m currently testing a Snowflake connection inPower BI Desktop (May 2026 edition) using RSA key authentication, and the connection works successfully in Desktop. However, after publishing the report/dataset to Power BI Service, the datasource fails with an Authentication Error. At this point: Power BI Desktop connects successfully to Snowflake using RSA key authentication Power BI Service does not authenticate successfully using the same setup The issue appears to be specific to the Service environment rather than the Desktop client Has anyone encountered this behavior?105Views0likes0CommentsDataflow Gen2 with SAP BW source cannot bind Lakehouse table
Issue Summary I found a reproducible issue in Microsoft Fabric Dataflow Gen2 when using SAP BW Application Server as the source and Lakehouse table as the destination. The Dataflow Gen2 can refresh successfully if the Lakehouse destination was already configured. However, when I try to open the destination settings and rebind the query to an existing Lakehouse table, the destination wizard fails with the error: Value should be defined This happens during the destination selection / binding step, not during data preview or refresh. Source Type SAP BW Application Server through Power Query / Dataflow Gen2. The query uses SAP BW cube functions such as: SapBusinessWarehouse.Cubes Cube.Transform Cube.ApplyParameter Cube.AddAndExpandDimensionColumn Cube.AttributeMemberProperty Cube.AddMeasureColumn Destination Microsoft Fabric Lakehouse table. The original load was created using the default Lakehouse destination and completed successfully. The Lakehouse table was created and refresh worked. Later, I tried to change/rebind the destination manually to the same existing Lakehouse table and change the loading method from Replace to Append. At that point, the destination wizard failed with: Value should be defined Important Finding I tested the same destination behavior with other sources: Source Rebind to existing Lakehouse table SharePoint Excel Works Table from another Dataflow Works SAP BW source Fails This suggests the problem is not caused by Lakehouse permission, workspace permission, table existence, or the destination wizard in general. The issue appears to be specific to SAP BW source metadata / Cube.Transform schema validation during Dataflow Gen2 destination binding. Reproduction Steps Create a Dataflow Gen2 in Microsoft Fabric. Use SAP BW Application Server as the source. Build a query using SAP BW cube functions such as SapBusinessWarehouse.Cubes and Cube.Transform. Configure a Lakehouse table as the destination. Run the dataflow. The first refresh completes successfully. Reopen the Dataflow Gen2. Open the Data destination settings. Select manual/custom destination. Choose an existing Lakehouse table. The wizard fails with: Value should be defined Expected Result The destination wizard should allow selecting an existing Lakehouse table and saving the destination mapping. It should support normal destination configuration such as Replace or Append, the same way it works for SharePoint Excel or another Dataflow table source. Actual Result The destination wizard fails before the mapping can be saved. The dataflow itself can still refresh if the previous destination configuration already exists, but I cannot safely rebind or modify the destination settings. Business Impact This blocks production setup for SAP BW ingestion into Fabric Lakehouse. We need to load SAP BW data incrementally into Lakehouse, but cannot reliably configure an existing Lakehouse table destination with Append mode using Dataflow Gen2 when the source is SAP BW. Current Workaround Use Dataflow Gen2 only to extract SAP BW data into a staging Lakehouse table with Replace mode. Then use a Fabric Notebook or SQL process to load data into the final table, for example: SAP BW ↓ Dataflow Gen2 ↓ Lakehouse staging table - Replace ↓ Notebook / SQL delete-insert or merge ↓ Final Lakehouse Delta table This avoids relying on Dataflow Gen2 existing-table destination rebinding for SAP BW queries. Request Please investigate whether this is a known Dataflow Gen2 issue with SAP BW source queries and Lakehouse destination binding. Specifically, please check whether Dataflow Gen2 has a bug or limitation when resolving schema metadata from SAP BW / Cube.Transform queries during existing Lakehouse table selection. Error Details Error message: Value should be defined Session ID from error dialog: ee47c976-888c-408f-ab30-60d3245b00f6 Environment Product: Microsoft Fabric Feature: Dataflow Gen2 Source: SAP BW Application Server Destination: Fabric Lakehouse table Issue area: Data destination / existing Lakehouse table binding450Views4likes0CommentsGateway 3000.314.5 - Microsoft.Mashup.Container.NetFX45.exe crashes on Virtual Machines (GPU-less)
Issue Summary The On-premises Data Gateway version 3000.314.5 (released April 27, 2026) fails to install on Virtual Machines without GPU acceleration. The previous version 3000.310.1 installs correctly on the same environment with a workaround. Environment OS: Windows Server 2019 Standard (Build 17763.8644) Machine type: Virtual Machine (no GPU acceleration) .NET Framework: 4.8 (Release 528049) WebView2 Runtime: 147.0.3912.86 Visual C++ Redistributable: 14.44.35211 Gateway version failing: 3000.314.5 Gateway version working: 3000.306 Steps to Reproduce Provision a Windows Server 2019 VM without GPU acceleration Download and run the Gateway installer version 3000.314.5 Observe the installation failing at the service start step Error Details From Windows Event Log: Application: Microsoft.Mashup.Container.NetFX45.exe Framework Version: v4.0.30319 Description: The application requested process termination via System.Environment.FailFast Message: Unexpected exception in background thread of Mashup container (error code -2146233088) Exception: CLR20r3 — FatalError From MSI log: Product: GatewayComponents -- Error 1920. Service 'On-premises data gateway service' (PBIEgwService) failed to start. Return value 3. Additional log evidence: Even with all workarounds applied simultaneously (--disable-gpu, --no-sandbox, --use-gl=swiftshader, WEBVIEW2_USER_DATA_FOLDER), the MSI log confirms the installer returns 1603 with Return value 3 at the INSTALL action, consistent across all attempts on this environment. Workarounds Attempted — None resolved on 3000.314.5 Workaround Result --disable-gpu --no-sandbox --disable-software-rasterizer ❌Crash persists --use-gl=swiftshader added ❌Crash persists WEBVIEW2_USER_DATA_FOLDER set with full permissions ❌Crash persists Visual C++ updated to 14.44.35211 ❌Crash persists Windows Defender exclusions added ❌Crash persists Performance counters rebuilt (lodctr /R) ❌Crash persists Service account changed to Local System ❌New error: "service is marked as interactive" Working Workaround Version 3000.306 installs successfully on the same VM with the following environment variables: WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS = --disable-gpu --no-sandbox --disable-software-rasterizer --use-gl=swiftshader WEBVIEW2_USER_DATA_FOLDER = C:\GatewayWebView2Data Expected Behavior The Gateway should install successfully on Virtual Machines without GPU acceleration, as it did in version 3000.306. Actual Behavior Microsoft.Mashup.Container.NetFX45.exe crashes with a fatal error during service initialization, causing the installer to roll back. This appears to be a regression introduced in version 3000.314.5. Additional Context The crash occurs because Microsoft.Mashup.Container.NetFX45.exe requires an interactive desktop session that is not available in VM service context The --use-gl=swiftshader flag (SwiftShader CPU fallback) does not resolve the issue in this version Community thread with full investigation details: [Re: On-premises Data Gateway 3000.314.5 - Microsof... - Microsoft Fabric Community]1.8KViews7likes3Comments
