Storage location in Azure Synapse Lake database

Question

I am wondering why both LinkedServiceName and Location URL required for tables in a Lake Database? Wouldn't reference to the linked service be enough?

The reason I want to only reference the linked service is that I can change storage account with only a change in the URL in the linked service, while now I have to replace the Location parameter for every table in my Lake database when I want to deploy to a different environment with a different storage account.

Answer 1

Hello @Mathias Opland

why both LinkedServiceName and Location URL required for tables in a Lake Database? Wouldn't reference to the linked service be enough?

LinkedServiceName is a reference to the linked service that defines the connection to the storage account. It contains the connection details such as the storage account name, access key, and other authentication details.

Location URL, on the other hand, specifies the location of the container within the storage account where the data is stored. It includes the storage account name, container name, and other path details.

When you create a table in a Lake Database, you need to specify both LinkedServiceName and Location URL. The LinkedServiceName is used to authenticate and connect to the storage account, while the Location URL is used to identify the container where the data is stored.

In summary, both LinkedServiceName and Location URL are required for tables in a Lake Database because they serve different purposes. LinkedServiceName is used to specify the connection information, while Location URL is used to specify the location of the data.

Please let me know if this helps with your initial query? Can we close this escalation?

Answer 2

Hi @SatishBoddu-MSFT!

I was just thinking it was unnecessary to provide both storage account in the URL and Linked Service. Sources and sinks in data flows only need relative path in addition to Linked service, i.e. LinkedServiceName and container/storagePath.

The reason I want similar behavior is that we have multiple environments, where the folder structure of the storage accounts are identical, but the storage account name is different. For dataflows we only have to switch the URL of the Linked Service during deploy, and everything works out fine. However, for the Lake Database we will have to add an override arm parameter for each new table to override the path to the storage account. If we forget to do this, our prod workspace can point to the dev storage account, and it would be hard to discover this error.