Cross Database Insert in Azure? - azure

Is it possible for me to insert some data from one database to another in Azure sql?
Let's say I have a trigger in db1 that updates some values in db2.
I read about elastic queries but it seems like they are read-only so they don't solve my problem.

You can't use cross-database in Azure Sql Server because databases can't see eachother physically , you could use elastic pools but they are Read Only.
A solution is to use SQL Managed Instance to upload your instance . This supports cross-database queries but it was expensive.

There was some previous discussion here about doing similar:
C# Azure Function trigger when SQL Database has a new row added without polling
There is also the Azure SQL Bindings for Azure Functions but they are input bindings and not triggers and they're still in preview and limited to C#, JavaScript and Python.
Azure SQL bindings for Azure Functions overview (preview)
There was a new announcement last week after MS Build however for Azure SQL Database External REST Endpoints Integration (hopefully they don't refer to it as ASDEREI) but this is currently in preview under Early Adoption Program (EAP).
Announcing the “Azure SQL Database External REST Endpoints Integration” Early Adoption Program

Related

Find Azure SQL replication problems through an API?

We are using Azure SQL as our database across multiple regions, with one primary and multiple secondaries.
The scenario is, we want to find if there are any active replication problems through some sort of API call / so we can integrate this into our overall environment.
Is there an Azure Management API / or SQL query we can run and build an API on top of - so we can some result like replica DB X is having problems and the data is outdated?
Azure doesn't have an API for this yet. But you should be able to build APIs on top of the views.
There are out of box views 'sys.dm_database_replica_states' and 'sys.dm_db_resource_stats' provided on Azure SQL Database that could be used for your requirement. However, I would recommend you to go through the below link and choose them appropriately:
https://learn.microsoft.com/en-us/azure/azure-sql/database/read-scale-out#monitoring-and-troubleshooting-read-only-replicas
https://learn.microsoft.com/en-us/azure/azure-sql/database/read-scale-out#data-consistency

What extra one gets by selecting Azure SQL Managed Instance vis-a-vis Azure SQL DB PaaS

I would like to know what extra benefits one get by choosing Azure SQL Managed Instance compared to Azure SQL DB PaaS. I know SQL Managed Instance is offered as a vCore based purchasing model only. Apart from this what is the extra add on and benefits that one gets over the other. Any reply would be appreciated.
With Azure SQL Managed Instance, you essentially get a full fledged SQL Server that you can control any way you want, just like you would control a locally configured SQL Server. All the power and access and customization you want.
With, Azure SQL DB PaaS, you are essentially getting a database service, so, you give up a lot of control.
For example, take server collation. With the database service, SQL_Latin1_General_CP1_CI_AS , is all you get. With the Managed Instance, its your server. So, go ahead and select whatever collation you want, just like how you would select the collation at the time of creatoin.
Another issue is with auditing, if that is something that is important to your setup. with SQL Managed Instance, auditing happens at server level, because, you are getting the full database server. With the database service, it only database, because, you are only getting a database.
These are just the main details that I found. more details here at this Azure doc - https://learn.microsoft.com/en-us/azure/azure-sql/database/features-comparison
Of course, Managed is going to cost you more because you are paying for the license of the SQL server too.
Lastly, for me, this is the almost (not the exact same thing) like you running your own File Server on a Windows VM on Azure (Managed Instance) versus, just using Blob Storage. In both cases, you are just trying to store some files, but its how much control you have.
I would say think about Azure SQL DB vs Azure SQL Managed Instance (MI) as
Azure SQL DB = Resources dedicated to individual DBs like a container. They are grouped under a Azure SQL Server but that SQL Server is just for grouping.
Azure SQL MI = Almost same as on-prem SQL Server except you don't have to worry about OS, backups, high availability.
Here is a good comparison.
https://learn.microsoft.com/en-us/azure/azure-sql/database/features-comparison
Hopefully this will help
Azure SQL Database - The usual PaaS way. You have vCore, DTU, and Serverless billing mode. And Elastic pool support.
Azure SQL Managed Instance - Similar as below. When you want to use instance-scoped features of Azure SQL Managed Instance like Service Broker, CLR, SQL Server Agent, and Linked servers. As if you have an SQL Server on premise, Azure is responsible for patching, upgrading version etc.
SQL Server on Azure Virtual Machines - Similar as above. But you are responsible for OS and SQL server upgrade.

Make REST call to API and save the result to Azure SQL every hour

I'm using this very useful SQLCLR script to make a REST call to an API and save the data on SQL Server on the fly.
I have created a stored procedure that withdraws new data every hour so my data are always updated.
I would like to have all this on Azure so I can then create a Power BI data visualization.
THE PROBLEM:
As soon as I try to transfer the database on Azure I receive this error:
TITLE: Microsoft SQL Server Management Studio
------------------------------
Could not import package.
Warning SQL0: A project which specifies SQL Server 2019 or Azure SQL Database Managed Instance as the target platform may experience compatibility issues with Microsoft Azure SQL Database v12.
Error SQL72014: .Net SqlClient Data Provider: Msg 40517, Level 16, State 1, Line 4 Keyword or statement option 'unsafe' is not supported in this version of SQL Server.
Error SQL72045: Script execution error. The executed script:
CREATE ASSEMBLY [ClrHttpRequest]
AUTHORIZATION [dbo]
FROM 0x4D5A90000300000004000000FFFF0000B800000000000000400000000000000000000000000000000000000000000000000000000000000000000000800000000E1FBA0E00B409CD21B8014CCD21546869732070726F6772616D2063616E6E6F742062652072756E20696E20444F53206D6F64652E0D0D0A2400000000000000504500004C0103006D85475F0000000000000000E00022200B0130000026000000060000000000007E45000000200000006000000000001000200000000200000400000000000000060000000000000000A00000000200004C1E01000300608500001000001000000000100000100000000000001000000000000000000000002C4500004F00000000600000FC03000000000000000000000000000000000000008000000C000000F44300001C0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000080000000000000000000000082000004800000000000000000000002E7465787400000084250000002000000026000000020000000000000000000000000000200000602E72737263000000FC030000006000000004000000280000000000000000000000000000400000402E72656C6F6300000C000000008000000002000000
(Microsoft.SqlServer.Dac)
------------------------------
BUTTONS:
OK
------------------------------
This happens because Azure SQL has some feature stripped off like SQLCLR or SQL Server Agent (for some obvious security reason).
Is there any alternative to SQLCLR on Azure?
Is there any alternative to SQL Server Agent on Azure?
Basically: how to automate a REST call to an API every hour and save the result to SQL Server on Azure?
I do not think there is a straight forward replacement for SQL CLR. However, there are some Azure offerings that might be interesting.
I suppose an alternative is using a scheduled azure function that calls the API and store the result in the Azure SQL Database.
Do mind that if the process takes longer than 10 minutes you cannot use a consumption plan for the Azure Function, which is the most cost effective probably.
Depending on the scenario, Azure Data Factory can also provide a solution. You can create a pipeline that calls the API and copies the data to Sql Server as outlined here, based on a schedule trigger.
Even though Azure Functions is great, you could even solve this without much code using Azure Logic Apps, a scheduled trigger, the http request and the mssql connector.
https://azure.microsoft.com/de-de/services/logic-apps/

How to manage CosmosDB Stored procedures, Function and Triggers as like SQL DB project

I am developing a Saas based application which has hybrid DB architecture (Azure SQL Server and Azure Cosmos DB).
To manage SQL Server Tables, Stored procedures, triggers and functions we will create a SQLDB project (.sqlproj). Also we can generate .dacpac and deploy in the sql server.
As like SQL, we will have collections, stored procedures, triggers and functions in Azure CosmosDB.
How to manage CosmosDB collection, procedure, trigger? Is there any project templete available to manage? Suggest a solution to proceed.
Based on my experience with CosmosDb, I believe there is nothing sort of project templates available for CosmosDb. Because it is not as easy as SQL Db project.
I suggest you will have to store them as json files in local solution version control and version them accordingly.
You could write necessary programming logic to execute these scripts/cosmos DB logic using SQL API for .NET or another platform. This way you are controlling the collections, udf, triggers etc from your code, and you can version your code accordingly.
More references here: https://learn.microsoft.com/en-us/azure/cosmos-db/programming
Azure CosmosDBs can be managed through ARM templates. You can use these to version your databases/collections/etc. See Microsoft.DocumentDB resource types documentation.

LINQ to SQL with SQL Azure

We are investigating moving to a cloud model and the Microsoft Azure PaaS platform.
Our current data layer is written using LINQ to SQL. Will it be compatible with SQL Azure?
Yes LINQ to SQL is compatible. But you have to keep 2 things in mind:
SQL Azure is not a dedicated machine for you alone. Your databases will run on machines with other customers. You may be throttled, you can encounter transient exceptions, ... That's why you should implement a retry policy. There's an article on TechNet explaining how to do this with LINQ to SQL.
Since SQL Azure is not a real SQL Server there are some limitations. Read all about those limitations here: General Guidelines and Limitations (Windows Azure SQL Database). If you're planning to move an existing database (with or without data) to SQL Azure, consider using a tool that supports SQL Azure like the SQL Database Migration Wizard (SQLAzureMW).

Resources