New board topics in Microsoft Fabric Community

Fabric Eventstream MySQL CDC scans all databases and does not emit row-level events

girishtharwani2 — Sat, 12 Sep 2026 09:17:46 GMT

Hello Fabric Team,

We are testing the Microsoft Fabric Eventstream MySQL CDC connector with an AWS RDS MySQL database.

The MySQL instance is accessible through a private IP, and Fabric connects through a VNet data gateway/private network connection. Connectivity is successful, and the connector remains Active without reporting processing errors.

Our MySQL environment contains the same table structure across multiple databases, following a pattern similar to:

application_<tenant>.sample_table

We configured the source to capture only one fully qualified table:

application_tenant1.sample_table

The MySQL configuration is:

log_bin = ON
binlog_format = ROW
binlog_row_image = FULL
The connection user has SELECT, SHOW DATABASES, REPLICATION CLIENT, REPLICATION SLAVE/REPLICA, and the required snapshot permissions.
Each Fabric source uses a unique Server ID.
CDC from the same RDS instance has previously worked successfully through another CDC platform.

However, we are seeing the following behavior:

Although only one fully qualified table is selected, Fabric/Debezium scans schema metadata for every accessible database and table on the MySQL server.
More than 45,000 schema events were generated across the tenant and history databases.
The schema events contain DDL such as DROP TABLE IF EXISTS and CREATE TABLE.
Snapshot mode is configured as Initial.
The selected table contains approximately 16,000 records, but Fabric emitted zero snapshot r events.
We committed a new insert into the selected table after schema discovery finished, but no c event was emitted.
Eventhouse receives the schema events successfully, confirming that the source-to-Eventhouse path is operational.
The Eventhouse destination stores the Debezium payload in a dynamic column using a mapper from payload to RawEvent.

Could you please confirm the following?

Is it expected for the Fabric-managed MySQL CDC connector to scan and publish schema events for every database when only one fully qualified table is selected?
Does Fabric expose or support settings equivalent to:
- database.include.list
- table.include.list
- schema.history.internal.store.only.captured.databases.ddl
- schema.history.internal.store.only.captured.tables.ddl
Why would the connector finish schema discovery but not emit existing rows from the selected table when Snapshot mode is Initial?
Why are committed inserts not emitted after the schema phase appears to finish?
Is there a known limitation involving AWS RDS MySQL accessed through a private IP and VNet data gateway?
What is the recommended supported destination pattern for this CDC stream?

Our main objective is reliable ongoing CDC capture. We are flexible about the landing destination and can use:

Eventhouse
ADLS Gen2 in JSON or Parquet
Fabric Lakehouse/OneLake
Snowflake as the final destination

Please let us know which logs, connector identifiers, timestamps, or additional configuration details would help investigate this behavior.

Thank you.

DAX: Scenario C values misaligned on X-axis without calculated Final End Date

baxidor — Fri, 11 Sep 2026 23:01:33 GMT

Hi everyone,I’m working on a Power BI report where I previously created two calculated columns:

A “Final Start Date” that, under a specific condition (let’s call it Scenario C), shifts the original start date forward by 5 working days from a delay date.
A “Final End Date” that applies the same working-day shift to the original end date whenever the start date was shifted.

I used the Final End Date on the X-axis of a visual and a simple SUMX + SUMMARIZE measure on the Y-axis to get the total value per lot. Everything looked correct. Now I want to avoid calculated columns. I’m using the cleaned original end date on the X-axis and writing separate measures for each scenario. All scenarios work fine except Scenario C because it's the one shifting days. For Scenario C the measure correctly returns the total value, but the values are no longer distributed on the X-axis the same way they were when I used the calculated Final End Date. The dates on the axis stay on the original end dates instead of the shifted ones.

is that even possible

And the measure I’m currently using for Scenario C looks like this (simplified structure):

How can I make the Scenario C measure “respect” the same working-day shift that the old Final End Date column applied, so that the values appear on the correct (shifted) dates on the X-axis, while still using only the original end date column and no calculated columns?

Thanks in advance!

Accessibility issue in the Share dialog of embedded Power BI reports

ugartema — Fri, 11 Sep 2026 20:49:47 GMT

Accessibility issue in the Share dialog of embedded Power BI reports

I would like to share an accessibility finding identified while testing an embedded Power BI report published as part of the content of an institutional website. The purpose of this post is to provide constructive feedback to the Microsoft Power BI team and the accessibility community, based on a real user experience with screen reader navigation.

Context

The issue was found during accessibility and usability testing of a Power BI report embedded in an institutional website of ARESEP, the public services regulatory authority in Costa Rica. The report was not being reviewed only as a visual dashboard, but also as interactive web content that should be usable by people who navigate with a keyboard and screen reader.

Test environment

Content tested: embedded Power BI report published within a web page.
Browsers tested on Windows: Microsoft Edge and Google Chrome.
Screen readers tested on Windows: NVDA and JAWS.
Browser tested on macOS: Safari.
Screen reader tested on macOS: VoiceOver.
Navigation method: keyboard and screen reader interaction.

Description of the issue

When navigating the embedded Power BI report, the interface includes several areas: an initial section with information, keyboard command references and an option to skip to the main content; the main Power BI content; and a footer with options such as zoom and sharing.

The accessibility issue appears when activating the Share button. After pressing this button, a modal dialog is displayed. However, keyboard and screen reader focus remains on the Share button instead of moving into the dialog. As a result, the user is not immediately informed that a dialog has opened and must manually search for the new content.

Additionally, the dialog contains a text field with the URL of the Power BI report, but there does not appear to be an explicit Copy URL button or a clear mechanism that automatically copies the URL to the clipboard. In practice, this means that a screen reader user has to locate the dialog manually, find the URL field, select or access the text, and copy it manually before being able to share the report.

Steps to reproduce

Open a web page that contains an embedded Power BI report.
Navigate through the embedded Power BI interface using the keyboard and a screen reader.
Repeat the test in Windows using Microsoft Edge and Google Chrome with NVDA and JAWS.
Repeat the test in macOS using Safari with VoiceOver.
Move to the footer area of the report where the Share button is available.
Activate the Share button.
Observe that a modal dialog appears visually, but focus remains on the Share button instead of moving into the dialog.
Try to access and copy the report URL from the dialog using only the keyboard and screen reader.

Actual behavior

The Share dialog opens, but focus is not moved to the dialog.
The screen reader focus remains on the Share button.
The user is not clearly informed that a modal dialog has opened.
The behavior was observed across the tested environments, including Windows with Edge and Chrome using NVDA and JAWS, and macOS with Safari using VoiceOver.
The URL is presented in a text field, but there is no clearly available Copy URL button or automatic copy behavior.
The user must manually locate the dialog and copy the URL, which increases effort and may create confusion.

Expected behavior

When the Share button is activated, focus should move directly into the modal dialog.
The dialog should be announced properly by the screen reader, including its purpose and accessible name.
Keyboard focus should remain within the dialog until the user closes it.
The dialog should provide a clear, keyboard-accessible Copy URL button.
Alternatively, if the focus is moved automatically to the URL field, the interface could provide a clear and accessible way to copy the URL to the clipboard.

Accessibility impact

This behavior affects people who use screen readers and keyboard navigation. If focus does not move to the modal dialog, the user may not know that new interactive content has appeared. This can make the Share feature difficult to discover, understand and use. The absence of a clear Copy URL action also increases the number of steps needed to complete a common task: sharing the report with another person.

Why this matters

Power BI reports are increasingly used as public-facing information tools. When these reports are embedded in institutional or government websites, their accessibility affects access to public information. Improving focus management and providing a clear keyboard-accessible way to copy the report URL would help ensure that users of assistive technologies can interact with Power BI content more independently and efficiently.

It is also important to note that, based on the tests performed, the main content of embedded Power BI reports can become reasonably accessible when report authors apply accessibility best practices. This includes providing clear labels, maintaining a logical tab order, using meaningful alternative text when needed, and designing interactive elements so they can be understood by assistive technologies.

However, the issue described in this post corresponds to the default embedded Power BI interface, not to the report content created by authors. Because of that, it is not something that can be fully solved through good dashboard design practices. It likely needs to be reviewed and addressed at the product interface level.

Suggestion for improvement

It would be valuable for Microsoft Power BI to review the accessibility behavior of the Share dialog in embedded reports, especially focus management when the dialog opens and the availability of a clear Copy URL button. This would improve the experience for screen reader users and align this interaction more closely with expected modal dialog behavior on the web.

I am sharing this finding as constructive feedback from accessibility testing performed in multiple browser and screen reader combinations, including Windows with Edge and Chrome using NVDA and JAWS, and macOS with Safari using VoiceOver. I hope it can help improve the embedded Power BI experience for screen reader and keyboard users.

Hallazgo de accesibilidad en el cuadro de compartir de informes Power BI incrustados

Quisiera compartir un hallazgo de accesibilidad identificado durante la revisión de un informe de Power BI incrustado como parte del contenido de un sitio web institucional. El propósito de esta publicación es aportar retroalimentación constructiva al equipo de Microsoft Power BI y a la comunidad interesada en accesibilidad digital, a partir de una experiencia real de navegación con lector de pantalla.

Contexto

El hallazgo se identificó durante pruebas de accesibilidad y usabilidad realizadas a un informe de Power BI incrustado en un sitio web institucional de la ARESEP, la Autoridad Reguladora de los Servicios Públicos de Costa Rica. La revisión no se realizó únicamente sobre el componente visual del informe, sino también sobre la interacción del contenido como parte de una página web que debería poder ser utilizada por personas que navegan con teclado y lector de pantalla.

Entorno de prueba

Contenido evaluado: informe de Power BI incrustado en una página web.
Navegadores probados en Windows: Microsoft Edge y Google Chrome.
Lectores de pantalla probados en Windows: NVDA y JAWS.
Navegador probado en macOS: Safari.
Lector de pantalla probado en macOS: VoiceOver.
Método de navegación: interacción mediante teclado y lector de pantalla.

Descripción del hallazgo

Al navegar por el informe de Power BI incrustado, la interfaz contiene varias zonas: una sección inicial con información, referencias a comandos de teclado y una opción para saltar al contenido principal; el contenido principal del informe; y un pie con opciones como zoom, compartir y otros controles.

El problema se presenta al activar el botón Compartir. Cuando se presiona este botón, se muestra un cuadro de diálogo modal. Sin embargo, el foco del teclado y del lector de pantalla permanece en el botón Compartir, en lugar de desplazarse hacia el cuadro de diálogo. Como resultado, la persona usuaria no recibe una indicación clara de que se abrió un nuevo contenido interactivo y debe buscar manualmente el modal.

Además, el cuadro de diálogo contiene un campo de texto con la URL del informe de Power BI, pero no parece existir un botón claro para copiar la URL ni un mecanismo accesible que permita copiarla de forma directa al portapapeles. En la práctica, esto obliga a la persona usuaria de lector de pantalla a localizar manualmente el modal, encontrar el campo con la dirección, seleccionar o acceder al texto y copiarlo manualmente antes de poder compartir el informe.

Pasos para reproducir

Abrir una página web que contenga un informe de Power BI incrustado.
Navegar por la interfaz del informe utilizando teclado y lector de pantalla.
Repetir la prueba en Windows con Microsoft Edge y Google Chrome, utilizando NVDA y JAWS.
Repetir la prueba en macOS con Safari, utilizando VoiceOver.
Avanzar hasta el área del pie del informe, donde se encuentra disponible el botón Compartir.
Activar el botón Compartir.
Observar que aparece visualmente un cuadro de diálogo modal, pero el foco permanece en el botón Compartir en lugar de moverse al modal.
Intentar acceder y copiar la URL del informe desde el cuadro de diálogo utilizando únicamente teclado y lector de pantalla.

Comportamiento actual

El cuadro de diálogo de Compartir se abre, pero el foco no se mueve hacia el modal.
El foco del lector de pantalla permanece ubicado en el botón Compartir.
La persona usuaria no recibe una indicación clara de que se abrió un cuadro de diálogo.
El comportamiento fue observado en los entornos probados, incluyendo Windows con Edge y Chrome usando NVDA y JAWS, y macOS con Safari usando VoiceOver.
La URL se presenta en un campo de texto, pero no hay un botón Copiar URL claramente disponible o un comportamiento automático de copiado.
La persona usuaria debe localizar manualmente el modal y copiar la URL, lo que aumenta el esfuerzo y puede generar confusión.

Comportamiento esperado

Al activar el botón Compartir, el foco debería moverse directamente al cuadro de diálogo modal.
El lector de pantalla debería anunciar adecuadamente el diálogo, incluyendo su propósito y nombre accesible.
El foco del teclado debería permanecer dentro del cuadro de diálogo hasta que la persona usuaria lo cierre.
El modal debería ofrecer un botón claro y accesible mediante teclado para copiar la URL.
Como alternativa, si el foco se mueve automáticamente al campo de texto con la URL, la interfaz debería ofrecer una forma clara y accesible de copiarla al portapapeles.

Impacto en accesibilidad

Este comportamiento afecta a personas que utilizan lectores de pantalla y navegación por teclado. Si el foco no se desplaza al cuadro de diálogo, la persona usuaria puede no saber que apareció nuevo contenido interactivo. Esto dificulta descubrir, comprender y utilizar la función de compartir. Además, la ausencia de una acción clara para copiar la URL aumenta la cantidad de pasos necesarios para completar una tarea frecuente: compartir el informe con otra persona.

Por qué es importante

Los informes de Power BI se utilizan cada vez más como herramientas de información pública. Cuando estos informes se incrustan en sitios web institucionales o gubernamentales, su accesibilidad incide directamente en el acceso a la información. Mejorar la gestión del foco y ofrecer una forma clara, accesible mediante teclado, para copiar la URL del informe ayudaría a que las personas usuarias de tecnologías de asistencia puedan interactuar con el contenido de Power BI de forma más autónoma y eficiente.

También es importante señalar que, a partir de las pruebas realizadas, el contenido principal de los informes de Power BI incrustados puede llegar a ser razonablemente accesible cuando las personas que los crean aplican buenas prácticas de accesibilidad. Esto incluye usar etiquetas claras, cuidar el orden lógico de tabulación, agregar textos alternativos cuando hacen falta y diseñar los elementos interactivos de forma que puedan ser comprendidos por tecnologías de asistencia.

Sin embargo, el hallazgo descrito en esta publicación corresponde a la interfaz predeterminada de Power BI incrustado, y no al contenido del informe creado por las personas autoras. Por esa razón, no es un aspecto que pueda solucionarse completamente mediante buenas prácticas de diseño del dashboard. Probablemente requiere ser revisado y corregido desde la propia interfaz del producto.

Sugerencia de mejora

Sería valioso que Microsoft Power BI revise el comportamiento de accesibilidad del cuadro de diálogo Compartir en informes incrustados, especialmente la gestión del foco cuando se abre el modal y la disponibilidad de un botón claro para copiar la URL. Esto mejoraría la experiencia de las personas usuarias de lectores de pantalla y acercaría esta interacción al comportamiento esperado de los cuadros de diálogo modales en la web.

Comparto este hallazgo como retroalimentación constructiva a partir de pruebas de accesibilidad realizadas en varias combinaciones de navegador y lector de pantalla, incluyendo Windows con Edge y Chrome usando NVDA y JAWS, y macOS con Safari usando VoiceOver. Espero que pueda contribuir a mejorar la experiencia de uso de Power BI incrustado para personas que navegan con lector de pantalla y teclado.

Date Formatting - Limited Options

Specker — Fri, 11 Sep 2026 18:23:56 GMT

I believe this changed with the most recent update, but why are the date formatting options severely limited now? My default format in dashboards was "mmm dd". Now to get that result, I have to create a new column with it formatted as text, and sort the column by the original date column. This does not always work, or I get weird errors about more than one value, so it can't sort. "mmmm dd" just doesn't hit the same with those longer month names.

I very much miss the feature of just typing in which format you wanted. Am I the only one facing this? Am I missing something?

Scheduled refresh starts in 10 minutes after the scheduled time - is this expected queue latency?

anilelmastasi — Fri, 11 Sep 2026 14:11:38 GMT

Hello,

I schedule refresh and refresh starts later than i set. In documentation it says it can start in 15 minutes from the beginning refresh hour but here is my environment:

Fabric Trial capacity (F64 equivalent) also Pro Workspace, single workspace, single semantic model — no other workloads on the capacity
Storage mode: Import
Data source: SQL Server
Gateway: On-premises data gateway

In Refresh history, the top-level Start time is 3:03:12 PM, but the underlying "Data" step doesn't begin until 3:13:31 PM, roughly a 10 minute gap. The actual refresh itself completes in 9 seconds, and the overall status is Completed with no errors. So the refresh is not slow, it simply doesn't start when scheduled.

No other semantic models, pipelines or notebooks on the workspace or capacity. What exactly does the top-level "Start" timestamp in Refresh history represent, the moment the job is enqueued, or the moment the scheduler picks it up? Understanding this would clarify where the 10 minutes is actually spent.

Thank you.

Business Central Data to Fabric

Saum02 — Fri, 11 Sep 2026 11:18:28 GMT

Hii All,

Has anyone explored the BC connection to it's underlying SQL database? Is there limitation to this approach? I need to get data from BC to fabric, is SQL database of BC worth exploring?

Manage access on a report and semantic model

PBI_2K26 — Fri, 11 Sep 2026 09:49:24 GMT

Hi all,

I've published a Power BI report in a workspace. I'd like to share it with a member of the functional team so they can edit the report — adding or modifying visuals — but without being able to edit the semantic model.

However, other reports in the same workspace should remain read-only for them.

Could you let me know how to set this up?

how to create support ticket

hircinelol — Fri, 11 Sep 2026 08:16:29 GMT

how to create support ticket

How to Configure Scheduled Refresh in Power BI for Data Connected via Zoho People API?

Agni2171 — Fri, 11 Sep 2026 07:24:51 GMT

Hi Community,

I have connected Zoho People API data to Power BI using Power Query (API calls), and the data refreshes successfully in Power BI Desktop. However, I am facing challenges when configuring Scheduled Refresh in the Power BI Service.

The main issue is that the Zoho People access token expires every hour. When the token expires, the API calls fail, causing scheduled refreshes to stop working.

I'm looking for advice on the following:

What is the recommended approach for implementing scheduled refresh with Zoho People API in Power BI Service?

How can the access token be refreshed automatically before it expires?

Is it possible to use a refresh token within Power Query or Power BI Service to generate a new access token during each refresh?

Does this scenario require an On-premises Data Gateway, Azure Function, Power Automate, or another middleware solution?

Are there any best practices for handling OAuth 2.0 token expiration when connecting to APIs from Power BI?

Has anyone successfully implemented automated scheduled refresh for Zoho People API data? If so, could you share your architecture or approach?

Current Setup:

Data Source: Zoho People API

Connection Method: Power Query Web/API calls

Authentication: OAuth Access Token

Token Validity: 1 Hour

I would appreciate any guidance, sample implementations, or documentation that explain how to handle token renewal for Zoho People API integrations with Power BI scheduled refresh.

Bug: QuickBooks connector (QuickBooks for Pipeline) fails OAuth login

Vitaliy3 — Fri, 11 Sep 2026 06:19:22 GMT

When attempting to create a connection of type QuickBooks for Pipeline (Cloud category) via Manage Connections and Gateways in Microsoft Fabric, with the authentication method automatically set to OAuth 2.0, clicking the Edit credentials button results in an error when trying to initiate the OAuth login flow.

Error message:

Unable to start OAuth login for this data source. Connection string is not supported.

Details: Query contains unsupported function. Function name: QuickBooksForPipeline.Contents

Session Id: 6fb86dae-dc71-4a06-8f7f-b99aee7885df

RequestId: 710bfcb8-ff7a-444d-90dc-c2dcc311e0f9

Cluster URI: https://api.powerbi.com

Status code: 400

Time: Fri Sep 11 2026 07:54:51 GMT+0300 (Eastern European Summer Time)

Steps to reproduce:

In a Fabric workspace, open a Copy Data activity (Source) or go to Manage Connections and Gateways.

Click "+ New" to create a new connection.

Select connection type Cloud.

Search for and select QuickBooks for Pipeline as the data source.

Authentication method is automatically set to OAuth 2.0.

Click Edit credentials.

The error above appears instead of the expected QuickBooks OAuth consent screen.

Expected behavior: Clicking Edit credentials should open the standard Intuit OAuth 2.0 consent screen, as described in the QuickBooks connector documentation for Data Factory / Fabric pipelines.

Impact: It is currently impossible to create a working QuickBooks Online connection in a Fabric pipeline using this connector, which blocks migrating an existing pipeline (where tokens are currently passed manually as parameters) to native OAuth authentication.

Environment: Microsoft Fabric (trial capacity), browser: Chrome, date: 2026-09-11.

Input Slicer

klimkiv — Fri, 11 Sep 2026 06:02:35 GMT

Input Slicer is working with text field and not working with numeric fields. Is it by design?
thank you

Incremental refresh is not working as expected

Mahipal — Fri, 11 Sep 2026 05:13:10 GMT

I have setup incremental refresh in powerbi using one of the date/time column and published to service. When i go and refresh it for the 2nd time also, it is taking same amount of time. My data source is Snowflake.

2. = Table.SelectRows(CASES_Table, each [LASTMODIFIEDDATE] >= RangeStart and [LASTMODIFIEDDATE] < RangeEnd).

Enquiry about year to year % measurement

epang — Fri, 11 Sep 2026 04:03:48 GMT

I have a date dimension table and 2 tables Fact tables. The fact tables are cases and breaches. the relationship is one case to many breaches. One date can have many cases. I would like to calculate the YTD and Previous YTD count of cases and % change for year, quarter for last few years. How can I do that? someone has provided some dax. My current formula is

1. YTD Incidents = CALCULATE([Number of cases],DATESYTD('Cases'[Lodged Date].[Date]))

2. PYTD Serious Incidents =

CALCULATE( [YTD Incidents],

SAMEPERIODLASTYEAR(' Cases'[Lodged Date].[Date]))

3. YonY_Cases_%_Change =

VAR CurrentRate = [YTD Incidents]

VAR PriorRate = [PYTD Incidents]

VAR PctChange = DIVIDE(CurrentRate - PriorRate, PriorRate, 0)

VAR Arrow = IF(PctChange > 0, "▲ ", IF(PctChange < 0, "▼ ", "")) RETURN Arrow & FORMAT(PctChange, "0.0%")

Someone has provided me the following DAX. how can i use that to generate YtoY % change, YTD vs PTD % change, quarter to quarter % change? thanks.

VAR SelectedYear =

SELECTEDVALUE('dimDate'[Year])

VAR MaxDataDate = [Latest Data Date]

VAR StartDate =

DATE(SelectedYear, 1, 1)

VAR EndDate =

IF(

SelectedYear = YEAR(MaxDataDate),

MaxDataDate,

DATE(SelectedYear, 12, 31)

)

And used StartDate and EndDate to filter

Similarly, for previousYear:

VAR SelectedYear =

SELECTEDVALUE('dimDate'[Year])

VAR MaxDataDate = [Latest Data Date]

VAR StartDate =

DATE(SelectedYear - 1, 1, 1)

VAR EndDate =

IF(

SelectedYear = YEAR(MaxDataDate),

DATE(

SelectedYear - 1,

MONTH(MaxDataDate),

DAY(MaxDataDate)

DATE(SelectedYear - 1, 12, 31)

)

MS Power BI integration towards MS PowerPoint

EWA_212376 — Fri, 11 Sep 2026 00:07:13 GMT

Dear community,

One of our team members wants to integrate MS Power BI (live-query) into MS PowerPoint and therefore he needs to install the add-in for the application.

Unfortunately it does not who the required item in the ribbon within MS Power BI service:

I have also checked and unless I am not having the overall admin-role within MS Power BI service I am also not seeing the item for download:

I also checked the settings within the admin portal and it seems to be correct, since everything is activated for the whole organisation:

Did I miss something or does anyone have a hint for me on this purpose?

Best regards and thanks in advance

Carsten

How to calculate Route based on repeating cycle

damit23183 — Thu, 10 Sep 2026 21:26:34 GMT

HI,

I have this table A:

Here you can see id has different route. So, when route is not repeating than good path and if route is going back to any previous route, then its bad path. Like image below

How to achieve final visuals like image below?

Thanks

Setting up BI Report subscription for Non Licensed Member

Natsu177 — Thu, 10 Sep 2026 21:24:58 GMT

Hi everyone,

I'm looking for a clear answer regarding Power BI report subscriptions and licensing.
Suppose:

I have a Power BI Pro or Power BI Premium Per User (PPU) license.
The report is hosted in a Pro or PPU workspace.
I create an email subscription for a report.
The recipients are internal users with no Power BI license at all (no Pro, no PPU, and no Fabric capacity assigned to them).

Can those unlicensed users receive the report subscription email, yes or no?

I'm specifically trying to understand whether a licensed Pro/PPU user can create subscriptions for completely unlicensed internal users when the report is in a Pro or PPU workspace.

Thanks in advance for any clarification.

Databricks connector automatically switches to ADBC 2.0 – ODBC issue

Fern_21 — Thu, 10 Sep 2026 20:41:52 GMT

Hi all!

Since the August release of Power BI, I’ve noticed that when using the Databricks connector, the implementation is automatically set to 2.0 (ADBC).

However, my environment relies on ODBC, so I had to manually change the setting back to System Default in order to get the connection working.

Even after switching back to System Default, I’m still experiencing issues with the Databricks connection.

Has anyone else experienced this behavior with the August Power BI release?

Is there a recommended way to force Power BI to use ODBC instead of ADBC?

Thanks

Latest Date Feature

AH1997 — Thu, 10 Sep 2026 20:41:24 GMT

How is there not a feature to default your date slicer to the max date of the dataset? Feel like this has been needed for years and the workaround is do clunky. Any new tips?

Fabric Copy Activity fails in Query mode but succeeds in Table mode through an on-premises gateway

alisaleh — Thu, 10 Sep 2026 20:25:01 GMT

Hi Fabric Community,

I am using a Microsoft Fabric pipeline Copy Activity to copy data from a Fabric Lakehouse to an on-premises SQL Server database through a dedicated on-premises data gateway.

I tested the Copy Activity using both of the following source connection types:

Lakehouse connection
Lakehouse SQL analytics endpoint connection

With both connection types, the behavior is the same:

Lookup Activity: Successful
Script Activity: Successful
Copy Activity using Table mode: Successful
Copy Activity using Query mode: Fails

When the Copy Activity source is configured with Use query = Query, it fails with the following error:

ErrorCode=SqlFailedToConnect,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Cannot connect to SQL Database. Please contact SQL server team for further support. Server: 'xxxxxxxx.datawarehouse.fabric.microsoft.com', Database: 'LH_XYZ', User: ''. Check the connection configuration is correct, and make sure the SQL Database firewall allows the Data Factory runtime to access.,Source=Microsoft.DataTransfer.ClientLibrary,''Type=System.Data.SqlClient.SqlException,Message=A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server),Source=.Net SqlClient Data Provider,SqlErrorNumber=53,Class=20,ErrorCode=-2146232060,State=0,Errors=[{Class=20,Number=53,State=0,Message=A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server),},],''Type=System.ComponentModel.Win32Exception,Message=The network path was not found,Source=,'

However, when I change the source configuration from Query to Table and select the source table directly, the Copy Activity completes successfully.

Has anyone encountered this behavior?

Does Query mode use a different runtime, connector path, or metadata-discovery process when the Copy Activity runs through an on-premises gateway?

Are there any known limitations or additional gateway requirements for using a custom query as the source?

Any guidance on how to diagnose or resolve this would be appreciated.

Bronze data contracts for REST/API sources — workaround for Get Metadata's connector gap

damo_mac85 — Thu, 10 Sep 2026 20:15:32 GMT

For SQL sources, our pattern is: Copy activity lands the table to Parquet, Get Metadata pulls the source structure, a Notebook compares that structure to a JSON contract, and if it matches, a Copy activity promotes Parquet to Delta — if not, we notify instead.

Wanted the same for REST/API sources, but Get Metadata doesn't support REST connectors — so there's no direct "get source structure" step for an API.

Workaround: since Parquet stores its own schema, we skip Get Metadata for API sources and just read it back off the landed file:

Copy: API → Parquet (raw landing)

Notebook: spark.read.parquet(path).schema vs. JSON contract

Match → Copy Parquet to Delta. Mismatch → notify,

Questions for the community:

Anyone found a more native way to get REST schema before landing data?

Is anyone doing a pre-flight sample call to validate before pulling the full payload?

Any word on Get Metadata adding REST support?

Curious how others doing bronze contracts in Fabric have handled this.