Snowflake Connection Error in Power BI – “Invalid authkind provided: KeyPair”
Hi everyone, I'm having an issue connecting Power BI Desktop to Snowflake using Key Pair authentication. I generated an unencrypted private key, configured the corresponding public key for the Snowflake user, and then tried to create/update the Snowflake connection in Power BI using Key Pair authentication. However, Power BI returns: Invalid authkind provided: KeyPair The connection was working previously, but I am now unable to configure or update the Snowflake credentials. Environment Power BI Desktop: September 2026 Version: 2.158.1177.0 (26.09) x64 Windows: Windows 11 / NT 10.0.26200 Data source: Snowflake Authentication: Key Pair Private key: Unencrypted Snowflake legacy ODBC preview feature: Disabled The detailed Power BI error report also shows: System.ArgumentException ConnectionDataExtensions.AsCredentialDataCollection and the error occurs during: UpsertConnectionAsync This makes me wonder whether this could be related to the September 2026 Power BI Desktop release or the newer Snowflake connector/credential handling, rather than the Snowflake key itself. I have already: Generated an unencrypted private key Configured the matching public key in Snowflake Selected Key Pair authentication in Power BI Tried updating/recreating the connection Has anyone experienced the same issue with the September 2026 Power BI Desktop release? Is there any known issue or workaround for: Invalid authkind provided: KeyPair I will also attach the full Power BI error details and screenshot. Thanks in advance.
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.
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/tables
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. Thanks
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?
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.Issue: 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.PowerBI--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?
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?Dataflow 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 binding
