Power query steps can't be edited since Sept 26 update
The overhauled power query editor in power bi is not allowing edits on steps created via the UI. It's bad enough that adding Missing.Ignore disables the edit, but now I can't even reopen a Choose Columns step and change my mind. Same issue on Expand Fields after a merge, and Added Items on a SAP view.
Regression: Google BigQuery connector loses Native SQL Query UI on gear icon click
Hello Power BI Team, Following the recent updates and the rollout of the new BigQuery connector implementation (ADBC), the Power Query UI is experiencing a significant regression regarding the Value.NativeQuery step. Previously, clicking the gear icon on the "Source" step of a BigQuery connection opened a dialog box clearly displaying the Native SQL Statement, allowing for easy copying, pasting, and formatting. Now, this UI is completely missing or fails to map for BigQuery connections. As a BI Architect, this severely disrupts the workflow. Instead of a clean SQL text box (which is still perfectly functional and stable in the SQL Server connector), we are forced to use the Advanced Editor. This exposes the raw M code, wrapping the SQL in double quotes and converting all line breaks to #(lf), making it extremely tedious to copy/paste the query directly to BigQuery Studio for testing without manual text parsing. The SQL Server connector handles NativeQuery UI mapping flawlessly. The BigQuery connector needs to maintain this same parity and stability. Steps to Reproduce: Step 1: Connect to Google BigQuery and input a Native SQL query via Advanced Options. Step 2: Apply the step, then click the gear icon on the "Source" step to edit the SQL. Step 3: Notice the UI no longer provides the clean SQL input box. Please investigate and restore the Native Query UI parsing for BigQuery connections.[Fabric Copy Job] Unable to parameterize SQL Database name for Deployment Pipelines (CI/CD)
I spotted an issue with the Fabric Copy Job item regarding the parameterization of SQL Server sources within Deployment Pipelines. Scenario: I am using a Copy Job to ingest data from an on-premises SQL Server to a Fabric Lakehouse. My environment utilizes Deployment Pipelines to promote content from Dev to UAT/Prod. I am attempting to use Variable Libraries to handle connection differences across these environments. The Issue: While I can successfully bind the SQL Server Connection object to a Library Variable, the Database Name field in the source settings does not support parameterization or variable binding. It remains hardcoded. Consequently, when I deploy the Copy Job from the Development workspace to UAT/Prod, the job continues to target the hardcoded Development database name (e.g., fabnavtest1), which is incorrect for the target environment. Troubleshooting Steps Taken: Verified that the Connection ID is successfully parameterized using the Variable Library VL_FDL_Config. Attempted to locate the underlying JSON definition via OneLake Explorer (similar to the workaround available for Dataflow Gen 2 destination issues) to manually inject a parameter, but the Copy Job folder appears empty/inaccessible. Technical Evidence: Below is the JSON definition of the source. You can see that connectionVariableLibrary is set correctly, but the database property is a hardcoded string with no option to bind it to a variable. JSON { "properties": { "jobMode": "Batch", "source": { "type": "SqlServerTable", "connectionSettings": { "type": "SqlServer", "typeProperties": { "database": "fabnavtest1" }, "externalReferences": { "connectionVariableLibrary": { "variableName": "SQL_CONN_ID", "libraryName": "VL_FDL_Config" } } } } } } Impact: This prevents the successful use of Deployment Pipelines for Copy Jobs using SQL Server sources, as we cannot dynamically change the database target per environment. Thank you for your help
Data pipeline stored procedure activity connections not updating
I have a data factory pipeline with an activity that runs a stored procedure in a warehouse in the same workspace. When run in dev, it works fine, but after deploying to test using deployment pipelines and attempting to run the data pipeline in test, I get the below error: The server address (ending ho4e) referenced in that message is the dev workspace, but when I investigate the connection settings node in the test pipeline's JSON, I see that the server address is: The server address ending oxdey is the correct address, i.e. the test workspace, so the deployment pipeline has in fact updated that, but something is still in place attempting to connect to the dev workspace. I added a single space into the whitespace of the JSON, saved and reran, and the connection was made successfully and the pipeline was able to complete. I don't believe the error message is correct either - it uses my personal Warehouse connection in both cases, which is not dependent on workspaces. Clearly a bug! Repro steps: Create a Warehouse in a dev workspace Create a stored procedure in that Warehouse Create a data pipeline in the same workspace Add activity to pipeline to run that stored procedure Run in dev workspace Run deployment pipeline to deploy to test workspace Run data pipeline in test workspaceCMD Prompt Popping Up During Changes
Hi all, I’m seeing recently a recurring issue in Power BI Desktop where a brief CMD window appears during report load and sometimes during semantic model-related changes. After digging into it, I found that the CMD window is actually SQLDUMPER.EXE. From what I understand, SQLDUMPER.EXE is a Microsoft diagnostic utility that gets triggered when an internal Microsoft component crashes or throws an exception. In this case, the actions seem to be tied to msmdsrv.exe, which is the backend model/query engine used by Power BI Desktop. What the issue looks like The black CMD window appears briefly. It first happens while the report is opening, specifically during “Preparing report”. It can also happen later when making changes that affect the semantic model, for example renaming a field or making other model-related modifications. The issue does not seem to be a simple visual/UI problem. It looks more like the backend model engine is hitting an exception and SQLDUMPER is collecting a dump. My troubleshooting so far Confirmed the CMD window is SQLDUMPER.EXE Using process monitoring, I confirmed that the CMD window is SQLDUMPER.EXE. Looking deeper, the process triggering it appears to be msmdsrv.exe, which is the Analysis Services/model engine running behind Power BI Desktop. No issue with a PBIX that has no external file connection In my tests, the issue does not appear when the PBIX contains only embedded data and no external data source connection to a file. You can simulate it just entering a dummy data using "Enter Data" in power bi. Issue will not happen on those reports. Happens in both Store version and downloaded version I tested both: the Microsoft Store/App version the downloaded installer version The issue happens in both. Preview features do not seem to be the root cause Turning off some preview features, such as On-object interaction, seemed to reduce the frequency somewhat, possibly because they trigger semantic model changes more often. However, this did not solve the issue completely, so I do not think this is purely a preview feature problem. Cache clearing and fresh install did not fix it I tried: clearing cache fresh installation switching to the downloaded version None of these resolved the problem. Running Power BI as Administrator prevents the issue While investigating logs, I noticed some apparent file access-related problems involving msmdsrv.exe. That led me to try Run as administrator. When I ran Power BI Desktop as Administrator, the issue did not appear. I even turned all preview features back on and tested again as Administrator, and it still did not happen. Moving the PBIX to a simple local folder did not help I also moved the report to a simple folder path such as: C:\test. This did not solve the issue. Current conclusion So far, on my machine, the only thing that prevents the issue is running Power BI Desktop as Administrator, which is obviously not a real solution. At this point, I suspect this may be one of the following: a Power BI Desktop bug a permissions / file access / credential issue something related to external data source connections possibly some interaction between the local Analysis Services engine (msmdsrv.exe) and file-based external sources Main questions Is anyone else seeing SQLDUMPER.exe appear during “Preparing report” or during semantic model changes? Has anyone identified the exact trigger? Has Microsoft acknowledged this anywhere? Is there any proper fix besides running Power BI as Administrator? Thanks in advance. I’m sharing this in case it helps others narrow down the issue.Deployment pipelines fails valid scenarios in warehouses
I have a warehouse that contains references to other warehouses in the same workspace. This has caused errors when using the deployment pipeline between dev and test that do not arise when deploying a DACPAC via the publish option in the mssql extension of VS Code. Given the inconsistent behaviour between the DACPAC deployment and the pipeline deployment, I believe this to be a bug in the pipelines feature. In the first instance, when referencing the sys schema of other databases anywhere (e.g. in a stored procedure), we get an error with the CrossDbEnricher being unable to update the model owing to 'an element that has the same name'. This is referring to stored procedure code that does fully qualify the reference to sys.tables with the database name included. To reiterate, the code builds, deploys and runs fine from the mssql SDK, and works when run on the workspace server - this is only an issue in the pipeline. The project includes references to the required database: We also have parsing errors picking up ambiguities that don't exist. In this case, the table 'HesaField' mentioned does not actually contain the field 'MappedFieldName'. This issue occurred where the field was not qualified in the query with the table alias, and was resolved by adding the alias to qualify. However, this does constitute a failure of the parser as the query was valid SQL without the table qualification owing to the field only existing in one table. I have workarounds for these issues, so do not need any advice. I would just like to raise these as a bug since there is a discrepancy between the behaviour in the service and the supported SDK that follows the better development practices; the service should be able to support scenarios that the platform (i.e. the Fabric Warehouses SQL Server implementation) and development tools can.
Make warnings more helpful
"Object reference not set to an instance of an object" is a recurring issue in Power BI Desktop. In other words: "There's a problem, but I'm not going to tell you where it is". Rectifying the issue would be MUCH easier if Power BI would actually tell the user WHICH object refference is the problem!Power BI Desktop (.pbip/TMDL) crashes on measure context menu — "Cannot read properties of undefined
Hi, When opening a Power BI report in .pbip format (Git-integrated project with TMDL), right-clicking on a measure in the field list causes an error: "An error occurred while rendering the report". The root cause is a JavaScript exception — Cannot read properties of undefined (reading 'capabilities') — thrown inside RenameDeleteMenuItemHandlers.capabilitiesCheck, which handles the rename/delete context menu logic. The same report works without issues when saved as .pbix. The problem appears to be specific to models using TMDL storage with the Enhanced Report Format preview features enabled (PBI_tmdlInDataset, PBI_enhancedReportFormat) in Power BI Desktop version 2.156.951.0 (July 2026). Log trace below: Feedback Type: Frown (Error) Timestamp: 2026-07-30T07:19:36.5501556Z Local Time: 2026-07-30T09:19:36.5501556+02:00 Session ID: 6757d351-bc9a-440d-bbbb-b05fa3ba2fef Release: July 2026 Product Version: 2.156.951.0 (26.07)+c9381f8e5efc99c8de04425f1572e841914690d8 (x64) Stack Trace: Javascript:TypeError at j (https://ms-pbi.pbi.microsoft.com/minerva/scripts/desktop.min.js:1:11328572) at RenameDeleteMenuItemHandlers.capabilitiesCheck (https://ms-pbi.pbi.microsoft.com/minerva/scripts/desktop.min.js:1:6819972) at RenameDeleteMenuItemHandlers.getHandlers (https://ms-pbi.pbi.microsoft.com/minerva/scripts/desktop.min.js:1:6819480) at FieldListMenuStrategy.getItemMenuHandlers (https://ms-pbi.pbi.microsoft.com/minerva/scripts/desktop.min.js:1:6839277) at FieldListMenuStrategy.getMenu (https://ms-pbi.pbi.microsoft.com/minerva/scripts/desktop.min.js:1:6838621) at https://ms-pbi.pbi.microsoft.com/minerva/scripts/desktop.min.js:1:14910361 at PbiTreeComponent.handleMenuOperation (https://ms-pbi.pbi.microsoft.com/minerva/scripts/desktop.min.js:1:14909836) at PbiTreeComponent.handleContextMenu (https://ms-pbi.pbi.microsoft.com/minerva/scripts/desktop.min.js:1:14909278) at PbiTreeNodeComponent.handleContextMenu (https://ms-pbi.pbi.microsoft.com/minerva/scripts/desktop.min.js:1:14933651) at https://ms-pbi.pbi.microsoft.com/minerva/scripts/desktop.min.js:1:14932357 PowerBINonFatalError: {"AppName":"PBIDesktop","AppVersion":"2.156.951.0","ModuleName":"https://ms-pbi.pbi.microsoft.com/minerva/scripts/desktop.min.js","Component":"","Error":"TypeError","MethodDef":"j","ErrorOffset":"1:11328572","ErrorCode":""} OS Version: Microsoft Windows NT 10.0.26200.0 (x64 en-US) CLR Version: 4.8 or later [Release Number = 533509] Peak Virtual Memory: 86.8 GB Private Memory: 676 MB Peak Working Set: 869 MB IE Version: 11.1882.26100.0 User ID: 773dc98c-b763-4862-b5e5-dc6b73c7793c Workbook Package Info: 1* - da-DK, Query Groups: 4, fastCombine: Disabled, runBackgroundAnalysis: False. Telemetry Enabled: True Model Default Mode: Composite Model Version: PowerBI_V3 Enabled Preview Features: PBI_DatabricksAdbcVersionEnabled PBI_googleBigQueryAdbcVersionEnabled PBI_scorecardVisual PBI_setLabelOnExportPdf PBI_oneDriveSave PBI_oneDriveShare PBI_useModernPublishDialogs PBI_gitIntegration PBI_tmdlInDataset PBI_enhancedReportFormat PBI_enhancedReportFormatPBIX PBI_advancedSlicerTypeList PBI_aiNarrativesVisual PBI_copilotUnifiedTooling MashupFlight_EnableOracleBundledOdacProviderV2 PBI_sqlDbNativeArtifactsOnDesktop PBI_warehouseSnapshotArtifactsOnDesktop PBI_enableExportQueries PBI_DesktopNamedPipeBridge MashupFlight_EnableFirewallFlowsWithDataSources Disabled Preview Features: PBI_UseRedshiftODBCV2 PQ_UseBaseViewXmlForSharePoint PBI_snowflakeLegacyOdbcVersionEnabled PBI_SpanishLinguisticsEnabled PBI_qnaLiveConnect PBI_b2bExternalDatasetSharing PBI_onObject PBI_publishDialogsSupportSubfolders PBI_useModernMashupEditor PBI_customCalendars PBI_enableOracleBundledOdacProviderForDQ PBI_dynamicCalcColumn PBI_newVisualDefaults2026 PBI_dateSlicerPreselectionAuthoring Disabled DirectQuery Options: TreatHanaAsRelationalSource Cloud: GlobalCloud Recent Actions: SetOutspacePaneContractWidth, SetOutspacePaneContractWidth, SetOutspacePaneContractWidth DPI Scale: 100% Supported Services: Power BI WebView2 Runtime Version: 150.0.4078.105 WebView2 SDK Version: 1.0.2365.46Power 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
"Only show AI-Prepped items in standalone Copilot in Power BI Experience" has no effect
I have enabled the feature "Only show AI-Prepped items in standalone Copilot in Power BI Experience" in the admin portal. This feature states that "When this is turned on, the standalone Copilot experience in Power BI won't show users Fabric items unless they're designated as prepped for AI." I have created a simple data model for testing. I have deployed this model to a workspace that also has the setting "Only show AI-prepped items in the standalone Copiliot in Power BI Experience" marked as on. Firstly i marked the model as being "Prepped for AI" under "AI Preparation". All the questions returned the answers I expected. I then disabled this setting and waited a little while for it to take effect. My expectation was the model would no longer be accessable to the Copiliot queries. It could still see and access the data, while even acknowledging that this setting was on: It appears the "Only show AI-Prepped items in standalone Copilot in Power BI Experience" has no effect
