We had a few incidents here replication either stopped completely after a data centre crash or had irrecoverable errors. In all cases we had to fully restore database or delete and start again. We need the following features to help support replication and have smoother recovery from failures Start replication on GUI and API Stop replication on GUI and by API (The existing SQLDB API works here for Fabric) Query replication state on GUI and by API Resync either one table or all tables on GUI or by API. These features would allow for recovery from issues without having to do full restores and reduce customers down time. ... View more

The transactional nature of Fabric SQL DBs means these are a great SaaS offering for application data. However, the lack of an option to support selective deployment in pipelines (e.g., deploy Table A and Table B but not Table C since it is a work-in-progress) means your solution deployments have to be all or nothing. This would also benefit Fabric DWs as well, but I'll take what I can get. 🙂 ... View more

It would really help with backwards compat and frustrations connecting in SSMS if Fabric SQLDB allowed users to connect to master. This adds 2 improvements 1) In this way we could connect to SSMS and then change DB afterwards , which is very much a mainstream practice. we understand telemetry shows that this is the No1 connection error from SSMS. 2) Currently some features such as dacpac, VS package export from SSMS and 3rd party schema compares break due to this issue. ... View more

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. ... View more

If you add a (preview) Azure SQL Database to your Fabric Workspace, it shows under it two items: SQL Analytics Endpoint and Semantic Model. Please add the SQL Endpoint as well. And while you are at it, make the whole list able to expand and collapse with "> / v " or + / - icons. This will go a long way to user interface improvements. ... View more

Currently when using SQLDB if we enter the server name / dns into SSMS or another tool it will fail as the connection defaults to master and the yser has no rights. We then have to manually add database, which is a GUID iso impossible to remember!   Please allow the user(s) public rightsr in the master so that we can connect in SSMS and other tools and then select the database from pull down.   This is how every other edition of SQL works! ... View more

Hi Team, Great to get the ability to create a SQL Database via API are you working on the ability to return the connection details? To make it more useful it would be great if we could get the connection details for the created database to (similar to how we can get in warehouse).   ** Once completed can we update the offical documentation ASAP so the Terraform provided team can start using **   Return something like below:   {   "id": "5b218778-e7a5-4d73-8187-f10824047715",   "displayName": "SQLDatabase1",   "description": "A SQLDatabase description.",   "type": "SQLDatabase",   "workspaceId": "cfafbeb1-8037-4d0c-896e-a46fb27ff229"   "properties": {     "serverFqdn": "dqjx2zrgh4uejnetrut54cdkau-g3353rbpoubuvclqhgoznhkmji.database.fabric.microsoft.com",     "databaseName": "SQLDatabase1-b218778-e7a5-4d73-8187-f10824047715"   }, }   Thanks, Darren ... View more

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', 'Kenobi@Rebellion.Empire', '1900-01-01', 99), ('Try there is not', 'Yoda', 'MasterYoda@Rebellion.Empire', '1945-01-01', 99), ('UWAAHguuuhff', 'ChewBakka', 'Chewy@Rebellion.Empire', '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; ... View more

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! ... View more

Hi,   I am looking for the connector to connect database using pyspark notebook in the same Workspace, and unfortunatlly I have not get the right soluction. could you please help me on how can we connect?   Thanks in Advance, Venkat ... View more

Currenlty when connecting to a Database using SSMS we get an error if we dont put the name of the database in the COnneciton Properties (and no one ever remembers to do this). This leads for poor user experience and goes against "it just works" If the user had automatic rights in master (even just connect, then there would be no error message. ... View more

As an experienced SQL developer, the ability to quickly covert columns to lists greatly improves workflows.   I have developed functions that convert columns to lists that are of much use to me. Further, my column-to-list functions can be set to do a column-to-bracketed list or a column-to-quoted list. That functionality is a game changer.    Simple idea, but I guanrentee that SQL developers will appreciate it. Most do not develop their own column-to-list functions. Instead they often copy and paste lists in excel or 3rd party apps to convert.  ... View more

When using Fabric SQLDB replicaiton we often get isues replication tabels and the ONLY curent way to fix is to either contact support to restart replication or to comnpletely delete and restore database. We need a way to be able to restart juts 1 table or all tables following any issues.   Currently support can takke over 2 weeks to triage issues and restart replication which is a lot of down time for solutions. We need ot be able to self service maintenance of replication! ... View more

Hi ”Product team” Currently customers with private link enables on Fabric teanant at the start of the preview on November 19 cannot create a Fabric SQL database. Any change that this will change? I am making a POC on moving our workflow from Synapse to Fabric and thought that the Fabric SQL data base might be a good choice for custom logging (our data go to a lakehouse) but a bit surprised to find we are not able to even create a Fabric SQL database as we must use private link due to company policy.   Friendly regards Kim Tutein ... View more

When trying to browse list of databases to select correct one in SSMS or SSDT, we get error message below TITLE: Browse Server for Database ------------------------------ Database 'master' on server 'fkm4vwf6l6zebg4lqrhbtdcmsq-absyvg6llsuutcc3wwyid37nou.database.fabric.microsoft.com' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of '{6745DA45-6CB6-46FB-9E2A-DD54D201E9F7}'. (Microsoft SQL Server, Error: 40613) For help, click: https://docs.microsoft.com/sql/relational-databases/errors-events/mssqlserver-40613-database-engine-error ------------------------------ BUTTONS: OK ------------------------------ ... View more

Current situation: When you start viewing previews of your table in SQL Database, you will only see part of the column names, Values and also the preview mouseovers in a cut-off mode and are not able to adjust the windth an the values:     Future Situation: You're able to adjust the width of the column via drag & drop or even adjust it to the max-width of the values with a double click. Values will be displayed with their full length instead of being cut off.   ... View more

What you would like to accomplish: Introduce catalog-level “join groups” in Fabric/SQL to enable multiple columns across different tables (e.g., fact and dimension tables) to share a consistent dictionary encoding for join keys. This would ensure that identical string or UUID values are assigned the same internal integer code, making joins and group-bys on these keys significantly faster and more memory-efficient. DuckDB Feature Request I made: Shared / Common Dictionary Encoding for Join Keys includes more details on the motivation and potential approaches. BigQuery Feature Request I made https://issuetracker.google.com/issues/442600668  One important detail to highlight is that typical dictionary encoding is local to a column or file, so even if two tables both use dictionary-encoded columns (e.g., customer_id as a string), the integer codes won't match between them. This forces the engine to fall back to comparing the original string values during joins, completely negating the performance benefits of encoding. That’s the core issue this proposal aims to address. How this might work: Allow explicit declaration of “join groups” at the dataset or project level, so that specific columns across tables share the same dictionary domain. Example of a possible SQL API: -- Define a join group to align dictionary codes across tables CREATE JOIN GROUP customer_id_group ( fact_customer_daily.customer_id, fact_customer_orders_daily.customer_id ); -- Optionally rebuild or refresh the dictionary ALTER JOIN GROUP customer_id_group REBUILD; Internally, Fabric/SQL would persist and reuse a common dictionary for the grouped columns, ensuring that equivalent string/UUID values map to identical encoded integer IDs across tables and partitions. If applicable, reasons why alternative solutions are not sufficient: Manual mapping tables: Today, teams often maintain surrogate key lookup tables to replace string/UUID identifiers with integer IDs. This adds complexity, operational overhead, and data engineering effort. Per-table dictionary encoding (as in Parquet/ORC): While these formats support dictionaries, they are scoped to row groups or files, and don’t provide cross-table consistency. Other information (workarounds you have tried, documentation consulted, etc): Current practice in many warehouses (includingFabric/SQL) is to maintain mapping tables for surrogate integer keys derived from string or UUID identifiers. While effective, this approach requires extra ETL complexity and maintenance. Implementing catalog-level shared dictionaries inFabric/SQL could provide operational simplicity and significant performance improvements for users with large, join-heavy analytic workloads. That said, I also want to acknowledge that it's entirely possible systems like Fabric/SQL may already be implementing something along these lines internally, and as an external user, I wouldn’t necessarily have visibility into whether or how that’s happening. ... View more

Currently complext type (json, struct) are supported in Onelake endpoint but not in SQL endpoint which prevents these important payload data types to be explored or used in Power BI. In big data world such fields are very common as many data generated through IoT are partially parsed in individual columns and raw json payload is left for future use or as on need basis. Before parquet - we use to store them as MapType which make them easy to further use. Adding this feature will do both - parsing those field easy for end user and also migration of existing data possible. ... View more

We are having issues inititiating the mirrored tables for large tables. There is very little info on the net about removing the timeout. It would be nice if that is not a restriction for seeding new large tables ... View more