Fabric SQL Database dynamic data masking doesn't work
I've been doing some testing with Dynamic Data Masking to try and find out if/how it works. To do that, I'm running a script that works perfectly fine in SQL Server and Azure SQL Server. But it fails to mask the data in Fabric SQL Database. I got some confirmation yesterday at SQL Konferenz that this really looks like a bug and therefore I'm sharing the full code with you to reproduce and hopefully find a solution. DROP TABLE IF EXISTS dbo.MaskingTable; CREATE TABLE dbo.MaskingTable ( ID int IDENTITY(1,1), FirstName varchar(20) MASKED with (FUNCTION = 'Partial(3,"AbC",1)') NOT NULL, LastName varchar(30) MASKED with (FUNCTION = 'default()') NOT NULL, Email varchar(40) MASKED WITH (FUNCTION = 'email()') NOT NULL, SecretDate datetime MASKED WITH (FUNCTION = 'datetime("Y")')NOT NULL, TopSecretNumber int MASKED with (FUNCTION = 'RANDOM(1,1000)') ) INSERT INTO dbo.MaskingTable (FirstName, LastName, Email, SecretDate, TopSecretNumber) VALUES ('Hello There', 'Obi Wan', '[email protected]', '1900-01-01', 99), ('Try there is not', 'Yoda', '[email protected]', '1945-01-01', 99), ('UWAAHguuuhff', 'ChewBakka', '[email protected]', '2025-07-29', 99) SELECT * FROM dbo.MaskingTable CREATE USER NoUnMask WITHOUT LOGIN; GRANT SELECT ON dbo.MaskingTable TO NoUnMask; EXECUTE AS USER = 'NoUnMask' SELECT * FROM dbo.MaskingTable REVERT;
Add SQLDB for Fabric
Its great that Fabric gives us many ways to write delta-parquet files, but for meta data and logging we really need a different storage. One that has super low latency and optimised for small non-analytical queries. Ideally, what we need here is to be able to create a Fabric "SQLDB" and link or replicate it into a warehouse or Lakehouse This would let us store some data in a row store but also query it from Fabric in conjunction with Fabric tables. The killer use case here is meta data often which is the heart of any ETL automation solution.
maintain DatabaseID, Database Name and SqlEndPoint on a restore
When doing restore we always get a new database ID, Physical Name and SqlEndPoint, even if the database logical name is the same (eg restore over the top). This causes a massive increase in RTO as afer the restore all end points broke and configuration management had to be updated and re-tested. When doing a restore we need to have the ability to keep database exactly as it was, rather than always creating a clone. In a recent DR event it was 5 minutes to restore, but the 2 days before we stopped getting issues on end points and config change impact.
Delete multiple queries in Fabric SQL Database
In Fabric Data Warehouse I can select multiple queries and delete them in a single operation (hold down CTRL or SHIFT and select the queries I want to delete, then right click and click delete). However, in Fabric SQL Database it doesn't seem to be possible to select and delete multiple queries this way. Please make it possible, thanks!Enable Connection from Fabric Notebook to Fabric SQL Database
The core issue is the inability to directly access Microsoft Fabric SQL Databases from within Fabric Notebooks, despite the availability of JDBC and ODBC connection strings. The built-in notebook authentication token library appears to be missing Fabric SQL as an option. It does not currently appear possible (or at least not documented how) to access a Fabric SQL Server Database from within a Fabric Notebook. I see JDBC and ODBC connection strings, but these don't work apparently because the library to create authentication tokens is missing Fabric SQL as an option. Current Impact 1. Enterprises must create complex workarounds ("Rube Goldberg architectures") to establish basic data flows that leverage SQL Server 2. The platform fails to deliver on its "unified" promise, leading to a loss of faith in the Fabric brand 3. SQL Server's established strengths are not being leveraged effectively, further eroding trust that Fabric can deliver on enterprise data needs Summary This is a critical feature request that highlights a significant gap in Microsoft Fabric's platform integration. The inability to easily access Fabric SQL Databases from Fabric Notebooks undermines the platform's unified vision and creates unnecessary complexity for enterprise users. The request is well-justified, technically feasible, and would bring significant value to the platform.
SQLDB and DW and LH - Allow friendly server Name (DNS)
Currently the server name for SQLDB (and DW) is a double GUID of {tenant-Id-workspace-id.}database.fabric.microsoft.com This causes a lot of issues as 1. This is impossible to remember 2. We ahve no way to distinguish test from PRD We request user frirnedly DNS Names like Prodata-Sales-DEV.database.fabric.microsoft.com This would help clearly label an worksapce as DEV or PRD and avoid confusion and make the platform easier to work with.,Keep Database Name as Non GUID
When we connect to the DB we have to enter the Database Name whgich is a GUID. Please make this database name equal to the same name as trhe SQL End Point and database name in Fabric. This imporves usability, and allows for the same 3 part TSQL to run on SQL DB v SQL End Point. At the moment we have different TSQL Statements if we query SQLDB v SQL End Point which is not optimum
Read Data from Lakehouse inside a Fabric SQL Database (using T-SQL)
We are working on a migration project to Fabric and need to combine data from inside a SQL Database with data in a Lakehouse then write it to another table in the database. Due to T-SQL compatibility issue with Data Warehouse, we want to use a Fabric SQL database for the Gold layer. For example: SELECT * FROM SilverLakehouseDeltaTable x JOIN GoldDatabaseSQLTable y ON y.id = x.id This should be part of a INSERT / UPDATE or MERGE such as: INSERT INTO AnotherGoldDatabaseSQLTable (Columns) SELECT * FROM SilverLakehouseDeltaTable x JOIN GoldDatabaseSQLTable y ON y.id = x.id The ability to read data from OneLake in a Fabric SQL database would solve this problem.
Fabric SQL Database - Available via Data Pipeline Stored Procedure Activity
Tried using Fabric SQL database to hold the metadata tables for metadata driven ingestion. Fabric SQL Database is not supported as source in stored procedure activity in pipelines. We need to update log tables in our metadata db by using the stored procedure activity. Is adding Fabric SQL Database in stored procedure activity on roadmap soon? Without this option available Fabric SQL database is not a viable option to replace an Azure SQL DB at this time. Please prioritise this option, Fabric SQL database is available in the Data Pipeline lookup activity so hopefully not to much much effort to also add to stored procedure activity. Thanks
