Update queries in Azure SQL Data Warehouse

I’ve recently started working on a project where we working in the cloud with Azure SQL Data Warehouse:

“Azure SQL Data Warehouse is a cloud-based, scale-out database capable of processing massive volumes of data, both relational and non-relational”

For more information about Azure SQL Data Warehouse, see here.

Although we develop with the same T-SQL as we do using the on-prem version of SQL Server, I did come across a bit of a quirk when writing some update statements.

If we are using the on-prem version of SQL Server, when we need to update data, we would have a SQL query like:

That is a basic update to a specific row of data in the Sales.MyOrderDetails table, using a where clause to filter for the row.

Sometimes, it isn’t always as straight forward and we need to join to other tables, so that we can refer to attributes from those rows for filtering purposes. For example:

However, if we take this approach in SQL Data Warehouse, we get the following error.

SQL Data Warehouse doesn’t support ANSI joins in the FROM clause of an UPDATE statement (it is also the case for DELETE statements too). There is a way round it and it uses an implicit join.

Before we look at how the update query can be written, it is a good place to point out that Inner joins can be written in a couple of different ways to what we had above.

In an inner join, the ON and WHERE clause both perform the same filtering and they both return rows where the ON and WHERE predicate is true. Therefore, we could write an inner join as

or implicitly like,

However, it is normally best to stick with the original example rather than the implicit version as although it is still supported, it is an old deprecated syntax and not considered best practise.

So, in order to write an update query in SQL Data Warehouse that uses inner joins to filter the rows, the workaround is as follows:

In conclusion, most SQL statements written in Azure SQL Data Warehouse are written in the same way we would with he on-prem  version of SQL Server, however, there are some cases where the syntax differs slightly and I will be blogging more about these special cases as I come across them!