The last mile of Fabric: getting business edits back into your warehouse
Every Fabric implementation I have worked on hits the same wall at roughly the same moment. The pipelines are running, the semantic model is clean, the reports look sharp. Then someone in finance says: "the cost centre mapping is wrong for three rows, can you fix it?" And the elegant architecture answers with a spreadsheet attached to an email. This post is about that last mile, why it is harder in Fabric than people expect, and what the realistic patterns are for solving it. Why the last mile is genuinely hard Fabric is built around analytical read paths. That is the right design for the workloads it targets, but it means the write path for small, human-scale corrections is not obvious. The options most teams land on: A staging table plus a pipeline. Someone uploads a CSV to a Lakehouse folder, a pipeline picks it up, a notebook merges it. Works, but you have built a bespoke ingestion system for what is functionally a typo fix, and now you own it forever. A Power App over the table. Good fit for structured, form-shaped entry. Poor fit for the case where a controller wants to see two hundred rows at once, sort them, and fix the eight that are wrong. Direct SQL access. Fast, but you are handing UPDATE rights to people who do not write SQL, and there is no validation layer between intent and damage. Nobody fixes it. More common than anyone admits. The mapping stays wrong and a filter gets added to the report. The spreadsheet keeps winning because the shape of the work is a spreadsheet: a grid, a lot of rows, a few edits, sorted and filtered by someone who knows the domain. The bit people get wrong: Warehouse and SQL Database are not the same target If you are building or buying anything that writes back into Fabric, this distinction matters more than any other, and it is the thing I see glossed over most often. Fabric SQL Database behaves the way a transactional developer expects. Foreign keys are enforced. You get rowversion for optimistic concurrency. A multi-statement transaction commits or rolls back as a unit. If two people edit the same row, you can detect it and refuse the second write. Fabric Warehouse does not give you those guarantees. Constraints exist for query optimisation but are not enforced. There is no rowversion equivalent for conflict detection. Isolation-level hints are accepted and ignored. A multi-step write sequence can leave you partially applied if something fails midway. Neither of these is a defect. Warehouse is an analytical engine and those trade-offs are why it scales. But it means a write-back tool that promises "all your changes commit together, or none of them do" is telling the truth against SQL Database and stretching it against Warehouse. Practical consequences if you are building this yourself: Do not rely on the database to catch bad references. Against Warehouse you must validate foreign keys in your own layer, before you write, or you will silently create orphans. Build your own conflict detection. With no rowversion, the honest fallback is comparing the primary key plus the values you read, and refusing the write if the row moved underneath you. Decide what a partial failure means, and say it out loud. If step four of six fails, steps one to three are already committed. Your user needs to know that, in the moment, in plain language. Validate before you touch the database, not after. A whole-batch gate (nothing writes unless every row passes) is far kinder than discovering row 147 is bad after 146 rows have landed. What good looks like Whatever route you take, the same handful of properties separate a write-back path that survives contact with real users from one that gets quietly abandoned: It uses the caller's identity, not a service account. If the tool connects as a shared principal, you have lost your audit trail and your permission model in one move. Entra ID passthrough means the database's own security is still doing its job, and SUSER_NAME() in an audit trigger still means something. Validation is authored, not hardcoded. Required fields, ranges, allowed values, regex patterns, uniqueness. These change constantly and should not require a deployment. Type enforcement happens before the write. Text in a numeric column, four decimals in a decimal(9,2), a date that Excel helpfully reinterpreted. Catch these in the client, where the user can still see what they typed. Errors name the row and the reason. "Constraint violation" sends the user to IT. "Row 42: Region must be one of North, South, East, West" gets fixed in ten seconds. Nothing is installed server-side. The moment your write-back solution needs stored procedures or schema changes deployed into the warehouse, it becomes a change-management conversation and the timeline triples. Where we landed We ended up building this as an Excel add-in, because that removed the training problem entirely. The user opens a workbook, picks a table from the catalogue their credentials can see, edits the grid, and clicks publish. Validation runs as a whole-batch gate before anything is written, so a failed row blocks the commit instead of half-applying it, and the failures come back as a plain-language list. Against Fabric SQL Database that commit is a single transaction. Against Fabric Warehouse we run a separate execution path and tell customers plainly what it can and cannot promise, for exactly the reasons above. Making that distinction visible turned out to be a feature, not a caveat, because the alternative is a data engineer discovering it at 2am. It is called Workbook Connect (workbookconnect.com) and there is a free tier if you want to try the pattern rather than build it. But the honest summary of this post is not "use our thing." It is: the last mile is a real architectural problem, it deserves a deliberate answer, and Warehouse and SQL Database need different answers. Curious how others are handling this. Staging tables and pipelines? Power Apps? Something cleverer? Would genuinely like to hear it. Sander Allert works at Plainsight (plainsight.pro), a Belgian Data and AI consultancy.
Request for Help: Warehouse Update Step Fails Between 3:30 AM and 7:00 AM
Hi All, We recently changed our Fabric capacity start time from 7:00 AM to 3:00 AM, and I updated the SQL Server to Fabric Lakehouse data ingestion pipeline to start at 3:30 AM. At the end of the pipeline for each table ingestion, there is a step that updates the Latest Update Date and Time in to the warehouse. However, this step consistently fails until 7:00 AM. After 7:00 AM, the same process runs successfully without any issues. I've attached an image that illustrates the behavior more clearly. Could anyone help identify what might be causing this? Is there any time-based restriction, service dependency, or configuration that needs to be enabled before 7:00 AM? Any insights would be greatly appreciated. Thanks!
Warehouse cannot be opened due to inaccessible files or insufficient memory or disk space
Today, we saw a lot of our pipelines showing this error message: Message = Database 'xxxxxxxxxx' cannot be opened due to inaccessible files or insufficient memory or disk space. Basically, we were refreshing the tables in the fabric warehouse at night when we started getting these messages. We also observed that the warehouse was showing this "Recovery Pending" message: We reviewed the Fabric Capacity metrics app and observed that the workspace reached 6 TB (unfortunately, the app does not show the size of each object inside the workspace). We use the P1 capacity, which is supposed to allocate up to 100TB of data, so we don't know what is wrong with this. In that same workspace, we also have a couple of lakehouses ingesting daily data, and those were ok. We have different theories here: 1. We don't really have 6TB of data. We delete tables every 6 hours and recreate them with new records. We believe the real warehouse size should be around 500GB. 2. We believe the automatic System-created restore points, are duplicating the size of the warehouse to the level of reaching 6TB. (I know the documentation says that it is just the metadata, but because we are deleting the table and recreating again from scratch, I believe the data for the recovery needs to live somewhere.) 3. We can't delete those system-created restore points, and we can't adjust the settings to reduce the number of times per day or the number of days we want to keep them. The fabric warehouse has been in that Recovery Pending state for almost 24 hours, and I don't know what to do. I would buy more storage, but that is not possible because it is part of the overall SaaS solution. I also believe this is a warehouse issue, since the lakehouses in the same workspace are fine. Any ideas? Has anyone faced this situation?Has anyone successfully connected SAS 9.4 to Microsoft Fabric Warehouse SQL Endpoint via ODBC
Hello, We are evaluating whether SAS 9.4 can connect directly to the Microsoft Fabric Warehouse SQL Endpoint using SAS/ACCESS Interface to ODBC and Microsoft ODBC Driver 18 for SQL Server. According to the Microsoft documentation, Fabric Warehouse supports SQL Server-compatible TDS connectivity through ODBC. However, we have not been able to find any public examples or customer experiences specifically involving SAS 9.4. We would appreciate it if anyone could share their experience. Specifically, we would like to know: Has anyone successfully connected SAS 9.4 to the Microsoft Fabric Warehouse SQL Endpoint? If so, which version of SAS 9.4 (for example, M7 or M8) did you use? Which Microsoft ODBC Driver version did you use (e.g., ODBC Driver 18)? Were you able to use a standard LIBNAME ODBC connection and PROC SQL without any special configuration? Did you encounter any issues related to Microsoft Entra ID authentication, encryption, or TDS compatibility? Are there any Microsoft or SAS documents that describe this configuration or confirm that it is supported? Any implementation experience, best practices, or references would be greatly appreciated. Thank you!ALTER TABLE DW
I have been trying to use ALTER Table Alter Column on a data warehouse table but it does not sem to be supported. I have a table that has a column a column [row_sum] [bigint] NULL I want to change it to [row_sum] DECIMAL(38,6) NULL and add a new column But I am not being able to do that It is extremely frustrating, what does MS suggest the BI author should in such case, DELETE the whole table and start from scratch? Also, is ALTER Table be allowed in DW in future? Thank you in advance.
