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

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

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

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

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

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

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

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

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

When connecting to SQL Database from dataflow, Power BI reads/load "datetimeoffset "  as DATE/TIME/TIMEZONE, but in order to set incremental refresh we need just DATE/TIME. If change it to DATE/TIME on SQL Databse, searching is changing from "seek" to "scan" and searching time is increased.  So we would like Power BI load "datetimeoffset " as DATE/TIME ... 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

I suggest including the field parameters functionality in Azure Analysis Services,same as what already exists in power bi ... View more

When conectint to a Fabric SQLDB in SSMS  its is very difficult as we need to also enter the datbase name  (this is not so for any other SQL Edition)   We request that the default database for users be set the the Fabric SQLDB, so that they do not need to specify the database name in connections   It makes no sense to make master the defautl database if no one is allowed connect to it. ... View more

I would suggest that any data scientists who use Power BI do outlier detection directly from a data connection in Power BI inside a pivot table. You can easily program the Interquartile Range (IQR) statistical outlier rule into the creation of your pivot table from a data connection and have the results visualized inside your final pivot table. It works great and is faster than trying to pull data using Power BI onto a woksheet and then doing analysis from there. I created this video so that you can see how the rule actually works to analyze and visualize a simple column of data and then how a dashboard can be directly created from it. ... View more

Currently, if you start a manual refresh for a dataset (Azure SQL in my case), then start a refresh schedule for that dataset before the manual refresh finishes, the refresh schedule will be wiped when the manual refresh finishes (I have reproduced this many times).   This is either a bug, or this feature should be changed. The current behavior of wiping scheduled refreshes makes no sense. ... View more