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.,
Fabric SQL Database names: Remove GUID suffix
When provisioning a new Fabric SQL Database, after typing in the name I want, what I get is that name PLUS some random GUID characters. This just seems wrong. Nobody likes to have their stuff renamed. As I understand it by someone from Microsoft in the Fabric Community, this was done to ensure a unique name across the entirety of Microsoft Fabric. It would be nice if that was NOT a requirement. Maybe you can make it like Fabric Warehouses where it is the combination of the Tenant, Workspace, and Data Warehouse name that needs to be unique.
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.Allow Workspace Identities as an authentication method for Fabric SQL Databases
Currently the only method of authentication in Fabric pipeline connections to Fabric SQL databases is using OAUTH2, meaning that the credentials of a specific user need to be used (with all the attendant issues around user/credential expiry). By allowing the option of workspace identity for authentication, no user creds would be needed. Obviously correct access controls would need to be defined, but that's standard SQL Server maintenance.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 optimummaintain 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.Read Data from Lakehouse inside a Fabric SQL Database (using T-SQL)
It should be possible to query data in a Fabric Lakehouse directly in Fabric SQL database using T-SQL. For example I have the following scenario where I want to join data from a table in my Fabric SQL DB to a delta table in my lakehouse then insert the resultset into another table in my Azure SQL database: INSERT INTO AnotherGoldDatabaseSQLTable (Columns) SELECT * FROM SilverLakehouseDeltaTable x JOIN GoldDatabaseSQLTable y ON y.id = x.id This isn't currently possible with Fabric SQL Database.
Cross-database queries for live databases
Within Fabric SQL databases you can cross-database query in the warehouse connection. However cross-database querying from one live SQL database to another is not possible. It would be great to have this possibility with 3-part names: select* from [sqldatabase].[dbo].[table_A] By getting this migrating from on-prem SQL server or an Azure managed instance to Fabric will be easier.
Fabric - Warehouse + Database - Add syntax to SQL language for comments
Since the foundational format for one lake is the delta file format, why has no SQL syntax for adding comments to both Tables and Columns within tables. With Generative AI, it more important than ever to tag tables and columns with descriptions. Below is the syntax supported by delta files for tables. COMMENT ON TABLE table_name IS 'your desired comment';' Below is the syntax supported by delta files for columns. ALTER TABLE table_name ALTER COLUMN column_name COMMENT 'your desired column comment'; Please see vendors like Snowflake (warehousing) and PostgreSQL (database) that have implemented this syntax. It is alot cleaner than the stored procedure syntax in Fabric SQL database. Below is the comment on a table. EXEC sp_addextendedproperty @name = N'MS_Description', @value = N'This table contains information about library books on loan, including their ID, book ID, member ID, borrow date, due date, and return date.', @level0type = N'SCHEMA', @level0name = N'data_raw', @level1type = N'TABLE', @level1name = N'loans01'; Additionally, a comment on a column. EXEC sp_addextendedproperty @name = N'MS_Description', @value = N'LoanID', @level0type = N'SCHEMA', @level0name = N'data_raw', @level1type = N'TABLE', @level1name = N'loans01', @level2type = N'COLUMN', @level2name = N'The primary key for the loans table.';
