data modeling
4253 TopicsMake 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!27Views0likes0CommentsPower 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.4681Views0likes0CommentsPower 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"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 effect460Views0likes1CommentOption to set key column is missing in June 2026 release
Hello, In the June 2026 release, the option to set the key column seems to be missing ? Previously, the option was available below the Row label dropdown but is now gone. However, the columns that were set as key column in a table, still have the key (passport) icon in front of them. With the option to set the key column gone, it is not possible to add a new key column or to choose a different column as a key column. Please bring back the option in Power BI desktop. Setting the option in the TDML view is less user friendly.2.1KViews21likes7CommentsIssue: 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.284Views0likes1CommentDefault format string locale for dates and numbers does not work on date picker/between slicer
My data has US date format, but I am located in Denmark, and most of my users are in Europe, so I wanted to change the default format string locale for my dates to Danish, It seems to work on tables, but the slicer, when selecting the 'Between' option or the new 'Date Picker', the format seems to be locked to my browsers default setting. Using the new regional settings under 'This report' does not seem to affect these slicer options. My date format in the data is using the short date with the asterisk (*), so it should change automatically. Am I missing something or is this a bug?720Views0likes4CommentsDataflow error communicating with another service
This morning, several of my Power BI dataflows are failing with the following message: "We encountered an error during evaluation. Details: An error occurred while communicating with another service, please try again later. If this problem recurs, please contact support with this message." Is anybody else experiencing the same? I'm not aware of anything changing in our setup overnight, so can only asssume a service issue?427Views2likes1Commentæøå not supported after update 30th june?
TL;DR: Since ~2026-06-30, any Lakehouse Delta table with a non-ASCII character (æ/ø/å) in its name fails on the SQL analytics endpoint with "underlying location does not exist". The files exist in OneLake and read fine via Direct Lake/Spark/raw OneLake. Looks like a regression in how the endpoint encodes non-ASCII characters in the OneLake file path at read time. Worked the day before with no changes on our side. Summary Starting around 2026-06-30, querying any Lakehouse Delta table whose name contains non-ASCII characters (e.g. Norwegian æ, ø, å) through the SQL analytics endpoint fails with "underlying location does not exist". The same tables were queryable the day before with no changes on our side. The underlying data is intact and fully readable through other paths (Direct Lake, Spark, raw OneLake). This appears to be a regression in how the SQL analytics endpoint URL-encodes non-ASCII characters when building the OneLake file path at read time. Impact All tables with æ/ø/å in the name are unreadable via the SQL analytics endpoint (T-SQL, DirectQuery, and the Fabric portal table preview, which runs a SELECT under the hood). Reproduced across multiple independent lakehouses and workspaces in the same tenant. ASCII-named tables are unaffected. Direct Lake models and Spark are unaffected. Environment Fabric Lakehouse SQL analytics endpoint. Reproduced in more than one lakehouse/workspace on the same tenant. Capacity ID and region can be provided privately if a repro is needed. Exact error Failed to complete the command because the underlying location does not exist. Underlying data description: table 'dbo.Ødegård', file 'https://onelake.dfs.fabric.microsoft.com///Tables/Ødegård/part-00000-...snappy.parquet'. Reproduction Create a Delta table with a non-ASCII character in its name, e.g. Spørreskjema. Query it via the SQL analytics endpoint: SELECT COUNT(*) FROM dbo.[Spørreskjema]. Result: the error above. An equivalent ASCII-named table in the same lakehouse returns rows normally. Diagnostic evidence: The physical parquet files exist in OneLake and are byte-addressable only at the correct UTF-8 path. We requested the exact same file via the OneLake DFS API using different encodings of the ø in the folder name, and got: %C3%B8 (UTF-8, the correct encoding): 200 OK, the file exists. %F8 (Latin-1): 404 Not Found. %C3%83%C2%B8 (double-encoded UTF-8): 404 Not Found. Raw / unencoded ø: 404 Not Found. In other words, OneLake stores and serves the folder name as UTF-8 (NFC) and is byte-exact about it. Only the correct UTF-8 encoding resolves; every other encoding returns not-found. The SQL analytics endpoint is evidently requesting the file with a non-UTF-8 encoding of the non-ASCII character, so OneLake returns not-found even though the file is present. The catalog table name itself is correct clean UTF-8; the fault is in the path construction at read time. Corroborating signals: Direct Lake (VertiPaq) reads the same æ/ø/å tables correctly, verified via DAX COUNTROWS. This is because Direct Lake uses a different read path than the SQL endpoint and encodes the OneLake path correctly. refreshMetadata on the SQL endpoint does not help. It returns NotRun for existing tables, reporting them as already synced. And a brand new shortcut or table with a non-ASCII name syncs with status Success but still fails to read. So this is not a stale-metadata or sync issue. Timeline 2026-06-29 ~08:00: tables with æ/ø/å queried successfully via the SQL endpoint. 2026-06-30 (early): the same que change, no rename, no redeploy onour side. Delta commits before and after are identical WRITE/Overwrite operations. 2026-07-01: still failing. Current workaround For consumer-facing tables we added ASCII-named OneLake shortcuts pointing to the same data, plus SQL views that keep the original table names. Consumers can then read again using the exact same names as before. This is a temporary bridge, not a fix.428Views5likes1CommentPower 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?105Views0likes0Comments