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

Currently, databases are randomly assigned to a pool of logical servers and there is not a way to group databases under same logical server name. Please allow us to see all the SQL databases listed under the same logical server name. It would be ideal to create one connection to the server name. This eventually would make cross-database querying on the same server possible as well . ... 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

At present, Microsoft Fabric Managed Private Endpoints expose only the Sql and MongoDB sub-resources for Azure Cosmos DB. Teams that use the Gremlin API for graph workloads cannot establish a private-link connection from Fabric-hosted Spark notebooks, Data Engineering pipelines, or Warehouse queries. This prevents us from querying or loading graph data securely within OneLake and forces us to copy data outside the managed VNet or open public networking.   Requested enhancement Enable Gremlin (graph) API as a selectable target sub-resource when creating an MPE to an existing Cosmos DB account. Business impact Unlocks first-class, private, zero-egress connectivity to operational graph data for advanced analytics, fraud-detection models, and network-topology analysis. Removes the need for ad-hoc data pipelines or public endpoints, reducing security risk and cost. ... 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

Because of the current limitation for the Power BI Paginated report: no shared data sources / data sets no parametrised data source connection string allowed We are not able to change the online connectors used by the paginated report once it has been published to Power BI Service, to run against the different online CRM Dynamics environments we have available (e.g.: DEV, UAT, PRD) It would be great if this could be fixed as many of our reports (rdl files) would naturally need to run agaist the non prod environments during development, testing and bug fixing/enhancement changes, before they get published to run against the Production environment. ... 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

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

Cross Report Drill Down is a very useful and time saving feature that allows an organization to leverage previous work to enhance and support new reports with additional information and details. To implement this there is a specific requirement that the dataset and colunm names in the SOurce and Target reports match exactly. The reasoning is apparently so that a user can right click on an enabled visual and see other reports/pages portraying the same data and choose which to view.    While this is a laudiable and useful scenario, it requires unrealistic dicipline across an organization and across time to ensure dataset and columns names are standardized. And of course there is no garantee that the Target page will already be named appropriately for the context of the Drill Down process.   I would like to propose an alternative approach (while not affecting the current one):   Allow the developer to link a dataset from the Source Report to the Target Report by specifically identifying the datasets and key columns despite their having different names. Also, this alternative approach should eliminate the requirement for the user to decide which report and page to drill into and instead, select a single, "More Details"option in the Right Click context menu.  This would give the  developer ultimate control on how the cross report drill down works and eliminate the need for the datasets and column names ot match. Also, Target page names become irrelevant.   With this new approach, the entire library of PBi reports could be made available for Cross Report Drill downs without requiring that dataset and column names match and also eliminate the need to edit older report page names to reflect the context of a new Drill Down Link. ... 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

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

Our team is currently working on a project that involves loading a substantial amount of data from an on-premise Oracle database to Fabric. During this process, we encountered performance issues related to the Oracle ODBC driver. To ensure that the Oracle ODBC driver can meet our required performance levels, we conducted a series of tests focused on loading data to a parquet file. Our goal was to investigate the driver's capabilities rather than developing a production-ready solution. After several attempts with various implementations and libraries, we successfully loaded the same dataset to a parquet file on the gateway server in approximately 120 seconds, using the ODBC2Parquet tool written in Rust. However, when the load is initiated from Fabric, the same process takes between 300 seconds (with optimization of the fetch buffer size) and significantly longer without optimization. This performance discrepancy is a concern, given the substantial amount of data we need to load from our on-premise Oracle database to Fabric. It is important to note that there is a difference between the array size and the fetch buffer size. The array size refers to the number of rows that can be returned in a single fetch operation, while the fetch buffer size determines the amount of memory allocated for storing the fetched rows. We believe that the array size, which can be set using the ODBC API function "SQLSetStmtAttr" with the attribute "SQL_ATTR_ROW_ARRAY_SIZE", plays a crucial role in the performance difference. To rule out any potential bottlenecks, we conducted tests on the connection between the gateway server and Fabric and found no issues. Furthermore, the performance difference was also observed when loading the same table from the Oracle database to a local parquet file on the gateway server, with and without the array size parameter set. This confirms that the performance issue is related to the Oracle ODBC driver and the array size parameter, rather than any network or connectivity constraints. Interestingly, we observed a similar performance improvement when working with the native Oracle driver. Although the method for setting the value differs, increasing the fetch buffer size resulted in a substantial performance boost. We kindly request that this information be forwarded to your development team for evaluation. It would be highly beneficial if a feature could be implemented in the data gateway to set this attribute, potentially leading to significant performance improvements in our data loading processes from on-premise Oracle to Fabric. ... 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

Connecting Snowflake to Azure ADF can use Azure Private link. However, Snowflake to Fabric ADF cannot use the Private Link. At this point, the alternative is to setup a onprem gateway to connect Fabric (i.e. Fabric ADF) to Snowflake.   Please add this feature to Fabric ADF to connect to Snowflake via the Azure Private Link.  ... View more

Fabric Lakehouses support enabling the change data feed: https://www.serverlesssql.com/delta-change-data-feed-in-fabric-lakehouses/   This change data feed currently does not seem to be available through the SQL analytics endpoint. Adding change data feed support to the the SQL analytics endpoint would help to simplify replicating data from lakehouses to other systems. ... 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

Enable a native connector for Amazon S3 buckets in both Power BI Desktop and Power BI Service. This feature would allow users to directly connect to S3 storage without relying on third-party tools or custom scripts. Key benefits: Seamless integration with AWS S3 for importing data into Power BI. Improved security and governance through official support for authentication and permissions. Enhanced performance with optimized data retrieval from S3. Support for scheduled refresh in Power BI Service for S3-based datasets. This capability will significantly simplify workflows for organizations using AWS for data storage and Power BI for analytics. ... View more