One of the best things about Azure Data Factory is its ability to incorporate continuous integration and automated deployments quickly alongside your solution. However, if you’re working with SQL Server data sources and are using square brackets to interact with tables, then you may be in for a bumpy ride…
Obscure error messages can be the bane of an IT professionals life, often hampering or even preventing outright any successful resolution of issues. An example of this happened to me recently, during what appeared to be a run-of-the-mill Azure SQL automated deployment.
Migrating across from Microsoft Flow to Azure Logic Apps is ridiculously easy. However, there are some critical feature differences that you must make yourself aware of. One difference relates to how triggers actions work, particularly in tandem with an Azure template.
Resolving AADSTS50126: Invalid username or password Errors During Azure SQL Database Deployment Task (Azure DevOps Pipelines)
We saw a few weeks ago how to utilise Azure Active Directory (AAD) Security Groups to manage Azure SQL database access at scale. When using this feature, you must ensure database changes are deployed out using an AAD administrator account or similar, a task which may be difficult to achieve in an Azure DevOps Pipeline.
Sink Limitations with the Dynamics 365 Customer Engagement/Common Data Service Connector for Azure Data Factory
The Dynamics 365 Customer Engagement/Common Data Service connector for Azure Data Factory can, in most cases, fit into your data integration needs. However, it is worth highlighting the two field types which are, specifically, not supported; namely, the Customer and Owner field types.
By default, the Dynamics 365 Customer Engagement connector for Azure Data Factory V2 exposes a predefined list of fields, that must have data mapped to them for any Copy Data task to complete successfully. This behaviour can be impractical depending on your particular scenario; fortunately, there is a way in which you can override this.