I have created and approved a managed private endpoint in Azure Data Factory, targeting my Azure SQL server (which has public network access disabled).
I have also created a database user for the System Assigned Managed Identity.
When attempting to add a new linked service in the Data Factory portal, I am able to select my Azure subscription and the Server name, as shown in the screenshot below. However, the Database name dropdown never moves beyond "Loading..."
Attempting to create the linked service via Bicep instead seems to succeed - but reviewing the linked services blade, the linked service is not "Using private endpoint" - and my data pipeline fails.
Fix: Ensure SQL server name is all lowercase.
Checking my browser console whilst the above screen was displayed, I noticed an error relating to validation of the Server name, specifically "Servername cannot be empty or null. It can only be made up of lowercase letters, the numbers 0-9 and the hyphen. The hyphen may not lead or trail in the name."
My server name contained capital letters (although the Data Factory UI was rendering it in all lower case).
After recreating my Azure SQL server, with a name complying with the requirements above, I was able to set up the linked service without issue (both through the UI and through Bicep).
Try with enabling interactive authoting option.
https://learn.microsoft.com/en-us/azure/data-factory/tutorial-copy-data-portal-private
Related
I have an Azure Asp.Net Core Web App running with Azure SQL. The SQL server has a replica target in a different region.
This particular server is a Hangfire "task" server. It should participate in task execution along with the rest of the servers in the (logical) Hangfire cluster during normal operation (it should point toward MyPrimaryLiveSql.database.com).
In the event of a service outage in the primary region, the sql replica at BCDRSql.database.com goes from Read Only to Read/Write. I would now like the Task Server to automatically start using bcdrsql.database.com as its connection string for all connections going forward.
Is there a way in either Azure SQL or Asp.Net or Azure Web App Configuration or Entity Framework Core to dynamically choose/redirect the SQL server connection string depending on if the Database is in read only or read/write mode?
I can get the database read/write status via SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability');, but I'm not sure how to get my Data Context to use the BCDR connection string based on the result, as my DB Context is only initialized once during the startup sequence.
You can likely just us a failover group to solve this problem. Please read through this link: auto failover groups. Note that this works for the automatic DR path - there is also the other active geo-replication solution and you may need control over the failover yourself (Microsoft does it in the "auto" case). So please be aware of the level of control you need in each solution. (Of course, if you are choosing to failover you can likely get your app to do what you want then too since you are making a change yourself.
I am trying to create a pipeline to copy some data between Azure SQL databases on different servers, but creating a Linked Service using SQL authentication fails (and gives no helpful information, just a dialog box saying it failed). I think that the server VMs are in different tenancies or different subscriptions (I am not sure of the distinction), so I am guessing that the one I am working in cannot see the one I want the connection to go to. Is that likely, and what needs to be done to make it work? Any advice welcome, including RTFM if you can point me at the right one and it doesn't take weeks to wade through it!
In case anyone hits the same issue: the problem turned out to be the 'encrypted' checkbox in the self-hosted integration runtime (IR). Clearing this flag allowed the IR to see the target database, and the pipeline could then be created with the new connection set to use that IR. #Leon Yue: both databases are Azure SQL instances on Azure PaaS VMs.
I have a database that is sitting on on-prem sql server. I go to management studio and then select the database that I want to deploy on Azure and follow the guide. Eventually, I am getting a bunch of errors such as
One or more unsupported elements were found in the schema used as part of a data package.
Error SQL71561: Error validating element [dbo].[patientInfo]: View: [dbo].[patientInfo] has an unresolved reference to object [198.18.21.71].[db_cs_dw].[dbo].[invoice]. External references are not supported when creating a package from this platform.
Error SQL71562: Error validating element [dbo].[getAllClaimsByPatientId]: Procedure: [dbo].[getAllClaimsByPatientId] has an unresolved reference to object [198.18.21.71].[db_cs_dw].[dbo].[all_clients_view]. External references are not supported when creating a package from this platform.
Do I need to set up a linked server on my Azure sql server with [198.18.21.71]. Can I do that?
As others have rightly stated, you cannot set-up a linked server in Azure. The validation failures you're seeing are because 4-part [server].[database].[schema].[table] references have been detected, that aren't supported in Azure.
Assuming that your [db_cs_dw] database will also be hosted in Azure, you can perform an Elastic Query to perform the cross-database queries. There is a bit of set-up required to undertake this, including creating a security context, data source and External Tables to represent the [invoice] table or any other data you wish to access in the other database. Your old references to [198.18.21.71].[db_cs_dw].[dbo].[invoice] would now reference the External Table. You could also encapsulate this further by introducing Synonyms - so the synonym references the External Table and the [dbo].[patientInfo] view will reference the synonym.
Otherwise, you will need to host the data within the same database and have some kind of ETL/replication process in place to move/sync the data.
Do I need to set up a linked server on my Azure sql server with [198.18.21.71]. Can I do tHAT ?
you can't setup a linked server from Azure to onpremises..
as the error says,you need to resolve those conflicts by either removing the views or modfying them
Applied for preview access on behalf of my client roughly a month ago. Preview access was approved yesterday. Followed the instructions in the email, namely to create a logical SQL server and reply with the name. Was notified today that the aproval process for the logical SQL server was completed.
Now, when trying to create a new Azure SQL Data Warehouse, it sits there for about an hour before failing on an Update SQL database event. Property mentions statusCode NotFound, and the statusMessage contains code 45181 and message "Resource with the name '' does not exist. To continue, specify a valid resource name."
What am I missing here?
Thanks for alerting us to this issue. We have investigated the issue and have unblocked the preview access for your subscription. You should be able to proceed and provision an Azure SQL Data Warehouse. You can follow the Get Starting guide to provision your first database.
I have a Azure application that use different databases of different servers. This databases are independent, and each sector of my application uses only one database.
I try make a IP filter. This filter must identify the solicitant's ip, and allow access each database or not depending this filter. This give me a way for allow access to A and not to B for a IP, access to B and not to A for another IP, full access for another diferent IP... using the security of Azure.
It's this possible?
Thanks, I wait a answer!
PD: sorry for my horrible english!
Assuming you are referring to SQL Azure hosted databases, you can use Database-Level Firewall settings, which are documented here.
Create a database-level firewall rule by using the
sp_set_database_firewall_rule stored procedure. Add a new firewall
setting for Internet-based connections by specifying a unique name in
the name parameter of the sp_set_database_firewall_rule stored
procedure. Specify the lowest desired IP address in that range with
the start_ip_address parameter and the highest desired IP address in
that range with the end_ip_address parameter. The name parameter is of
the nvarchar data type and the start_ip_address and the end_ip_address
parameters are of the varchar data type.
Similarly, you can enable connection attempts from Windows Azure by
using the sp_set_database_firewall_rule stored procedure with the
parameters start_ip_address and end_ip_address equal to 0.0.0.0.
I'm sure you'll have already found a solution to this given its a couple of months old now, but just in-case...
Assuming I'm understanding correctly, you have a bunch of clients communicating to your application server, which in turn queries one of many database servers. The firewall suggested by mellamokb isn't an option as the client isn't actually hitting the database, and so what's needed has to sit on the application server.
Selecting the connection string used to access the/a database based on the client's IP address is probably what you're after here. If you also need to lock the database down using its native security, you will need to create a named user account for each of your clients.
Alternatively, you could investigate Federations on the Azure SQL Database and use either the client's IP address or a similar identifier as the distribution key.