Fabric Warehouse Git commit fails with “Maximum commit size exceeded” potentially due to XMLA.json
Based on the Fabric Warehouse Git integration documentation, the XMLA.json file should be excluded from Git integration workflows. Fabric should exclude this file from commits and updates to prevent the default semantic model metadata from being unintentionally stored in Git. [learn.microsoft.com] However, it appears that XMLA.json, or the associated semantic model metadata, may still be getting processed on the Fabric side while calculating or preparing the commit. This potentially causes the commit to exceed the maximum allowed size. Any One Face Same Issue, how to avoid above issue & prevent XMLA.json file from getting processes while git commit ?Git Commit Issue
Hello Fabric Community, I have a workspace that is connected to my GitHub repo. I used a personal access token to integrate GitHub with Fabric. Initially, I created the token for only one day and committed my items to GitHub. When I connected my GitHub repo again with a new token, I was unable to commit the changes that had been made so far because I could not find any items pending to commit in the source control pane "Changes" tab. PFA. Please suggest a solution or let me know the proper way to integrate my changes into GitHub again. Thanks in advance for any insights or guidance!
How to implement CI/CD for Lakehouse Delta table schemas and SQL Analytics Endpoint
Hi Microsoft Fabric Community, We have set up an automated CI/CD pipeline using Azure DevOps Repos, Git integration, and Microsoft's fabric-cicd Python library. Our current workflow is: 1. Feature workspaces are connected to Git feature branches. 2. A Pull Request merges changes into the dev branch. 3. Our Azure DevOps pipeline deploys Fabric items across target workspaces (dev → test → prod). The current behavior is: Control-plane items such as Notebooks, Data Pipelines, and Copy Jobs deploy and parameterize successfully. The Lakehouse item itself and its OneLake shortcut definitions also deploy as expected. However, Delta table schemas under /Tables and SQL Analytics Endpoint objects such as Views, Stored Procedures, and TVFs are not captured or deployed. Git integration appears to track the Lakehouse metadata but not the underlying Delta table structures or SQL Analytics Endpoint DDL. We have the following questions for the product team and community: Question 1 - Lakehouse Delta Table Schemas How can we implement automated CI/CD for Delta table creation and schema evolution across environments without requiring manual execution? Question 2 - SQL Analytics Endpoint Objects Since DACPAC / SqlPackage does not support the read-only SQL Analytics Endpoint, what is the recommended approach for implementing CI/CD for Views, Stored Procedures, and TVFs using Azure DevOps? Question 3 - Fabric Roadmap Are there plans on the Microsoft Fabric roadmap for native Git integration to track and synchronize SQL Analytics Endpoint objects directly alongside other workspace items? Any reference architectures, repository templates, recommended tools, or best practices for implementing this type of CI/CD workflow would be greatly appreciated. Thank you!
Unable to Configure Deployment Rules for a Direct Lake Semantic Model in Fabric
Hi Fabric Community, I’m facing an issue with Fabric Deployment Pipelines and would appreciate some guidance. I have a Power BI semantic model using Direct Lake mode, and I’m deploying it between two Microsoft Fabric workspaces. I am an Admin in both the source and target workspaces. However, when I open the Semantic model deployment rules, both Data source rules and Parameter rules are disabled/grayed out, as shown in the screenshots. I also confirmed that the tables in the semantic model are using Direct Lake storage mode using the TABLETRaits() DAX query. My questions are: Why are Data source rules and Parameter rules disabled for this semantic model? Is there any additional configuration required to enable these deployment rules? If deployment rules are not supported for this scenario, what is the recommended approach for changing the data source between environments? Any advice or explanation would be greatly appreciated. Thanks in advance!CDC vs Watermark: Choosing an Incremental Load Strategy in Microsoft Fabric
Why incremental loading matters If your source deletes rows or you need history, use CDC; if you only need inserts and updates and have a reliable "last modified" column, a watermark is simpler and works almost everywhere. That is the short answer. The rest of this post explains why. Reloading a whole table every night is fine at 50,000 rows. At 500 million it burns capacity units, hammers the source system, and stretches your refresh window. Incremental loading fixes this by moving only what changed since the last run. In Microsoft Fabric, the main tool for this is the Copy job in Data Factory. It supports both change detection approaches side by side, and can pick one per table. Knowing how each works helps you choose well and avoid silent data gaps. The watermark pattern A watermark load copies only rows whose "incremental column" value is higher than the highest value seen in the last successful run. The first run copies everything; each later run picks up where the last one stopped. The query behind it is simple: SELECT * FROM dbo.Orders WHERE ModifiedAt > @LastWatermark AND ModifiedAt <= @CurrentWatermark; In a classic pipeline you build this yourself: a Lookup for the old watermark, a Copy activity, and a step that saves the new value to a control table. Copy job removes that plumbing. It stores the watermark state for you, and a failed run resumes from the last successful one without data loss (Microsoft Learn). Copy job accepts these column types as a watermark: ROWVERSION – changes automatically on every insert or update; the most reliable choice on SQL Server-family sources. Datetime – columns such as ModifiedAt or LastUpdatedDatetime. Date – date-only columns; Copy job re-reads the last day to avoid gaps. String – values that can be read as datetimes. Integer – an increasing number. A column of another type can still work if you cast it to a supported type in the source query, as long as its values compare in order. File sources use the file's last-modified time as the watermark. The catch: a watermark only sees rows that still exist and whose column actually moved. Deleted rows are invisible, and rows with a NULL watermark are skipped on every incremental run after the first. Change data capture (CDC) CDC reads the source database's own change log instead of querying the table, so it captures inserts, updates and deletes exactly as they happened. You don't pick an incremental column; the database tells Fabric what changed. When a source table has CDC enabled, Copy job detects it, does an initial full load, and then replicates only changes on later runs (Microsoft Learn). Sources that support CDC in Copy job include Azure SQL Database, Azure SQL Managed Instance, on-premises SQL Server, Oracle, Snowflake, Google BigQuery, SAP Datasphere Outbound, and Fabric Lakehouse tables (via Delta Change Data Feed). You then choose how changes land in the destination: SCD Type 1 (Merge) – the default. The destination mirrors the current source: updates overwrite, deletes remove the row. SCD Type 2 – in preview. Copy job keeps every version, adding Valid_From, Valid_To and Is_Current columns. Deletes become soft deletes, so you keep a full audit trail with no custom code. Oracle sources don't support it yet. Copy job isn't the only CDC route in Fabric. Mirroring keeps a near real-time replica of an operational database in OneLake with almost no setup, and Eventstreams offers CDC connectors for streaming changes into Real-Time Intelligence. Microsoft's data movement decision guide compares the three. Side by side The deciding row is usually deletes: only CDC sees them. Consideration Watermark CDC Source prerequisite A column that always increases on insert or update CDC enabled on the source and supported by the connector Inserts Yes Yes Updates Only if the watermark column changes Yes Deletes No Yes History (SCD Type 2) No, unless you build it Built in (preview) Write methods Append or Merge Merge or SCD Type 2 Load on source Range scan on the watermark column each run Reads the change log; lighter on busy tables Setup effort Low; no DBA changes Needs CDC enabled, permissions, log retention Works with files Yes (last-modified time) No Source coverage Most database connectors A defined list of connectors Source: Incremental copy in Copy job, Microsoft Learn. Which one should you use? Three questions settle it for almost every table. If CDC is the right answer but you can't enable it on the source, fall back to a watermark and catch deletes with soft-delete flags or a periodic key comparison. Tips and pitfalls For watermark loads Prefer ROWVERSION over app timestamps. An application can forget to update ModifiedAt; the database never forgets a rowversion. Watch for NULLs. Rows inserted later with a NULL watermark are never picked up. Make the column NOT NULL with a default. Catch deletes another way. Use soft deletes (an IsDeleted flag that also bumps the watermark), or run a periodic key comparison against the source. Use Merge, not Append, for updates. Append writes a second copy of every updated row. For CDC loads Don't mix table types in one job. If a Copy job holds both CDC-enabled and non-CDC tables, it falls back to watermark for all of them. Split them into separate jobs. Size log retention. If the job is paused longer than the source keeps its change data, you will need a full reload. Know the current limits. Copy job captures net changes only (not every intermediate change) and supports only the default capture instance. For Lakehouse sources, enable Change Data Feed yourself; Copy job can't detect it (Microsoft Learn). For both Reset carefully. Resetting incremental state forces a full read on the next run but doesn't clear the destination. With Append, truncate the target first or you'll get duplicates. Plan for schema changes. New source columns aren't synced automatically, and a dropped column that's in your column mapping fails the run. Conclusion Watermark and CDC aren't rivals; most Fabric estates use both. Use a watermark for append-heavy fact tables, files, and sources you can't change. Use CDC wherever deletes or history matter, which is most dimension and master-data tables. Copy job makes the choice cheap to revisit: it detects CDC-enabled tables, handles state for you, and lets you reset per table. Start with the table that hurts most in your nightly full load, pick the method from the guide above, and measure the capacity you save. Sources Incremental copy in Copy job – Microsoft Learn Change data capture (CDC) in Copy job – Microsoft Learn Choose a data movement strategy – Microsoft Learn Copy job enhancements on incremental copy and CDC – Microsoft Fabric Blog
DP-600 Voucher
a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } Hi everyone, I recently passed the DP-700 Microsoft Fabric Data Engineer Associate certification and am now planning to take DP-600 (Microsoft Certified: Fabric Analytics Engineer Associate) while the Fabric concepts are still fresh in my mind. Unfortunately, I wasn't able to use a previous DP-600 voucher when I first received it as I wasn't ready for the exam at the time. I was wondering if anyone is aware of any current voucher opportunities for DP-600, or has an unused voucher that they won't be using and is transferable (if permitted by the voucher terms). Any guidance would be greatly appreciated. Thanks in advance! Regards, Amanul
