I’ve worked with SQL Server for several years now, and I am continually amazed at its capabilities, Recently, my work in this area has focused on the products change tracking feature, a nifty tool that can assist you in monitoring how your data evolves.
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.
Keeping things simple is an idea I like to promote at all times, particularly in the world of IT. Adopting this mantra can lead to fewer headaches and, as a recent example involving Azure Template deployments within Visual Studio demonstrates, a much faster resolution to your particular problem.
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.
When you are amid a pesky IT issue, it can be difficult determining whether the problem is down to a bug/system fault or human error. Like this recent example involving Azure Data Factory illustrates, it is generally best to assume the latter, to avoid any prolonged difficulty.
The ability to consume Application Insights data from directly within Power BI is an excellent feature in what is already a pretty outstanding product. However, there will likely be some steps that you have to follow to ensure that your reporting solution is secured, using an appropriately privileged API key.
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.
Azure SQL Server has long supported the ability to use Azure Active Directory user accounts to access and work with databases. What you may not know is that it is also possible to add users via membership of a security group, a feature which, I believe, is incredibly useful for managing large-scale deployments.
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.