A Fine Slice Of SQL Server
Robert Cain has a post dedicated to the strcat() function in KQL:
The
strcatfunction has been shown in previous articles, but it’s so useful it deserves a post all of its own.As usual, the samples in this post will be run inside the LogAnalytics demo site found at https://aka.ms/LADemo. This demo site has been provided by Microsoft and can be used to learn the Kusto Query Language at no cost to you.
Read on to (re-)learn the power of string concatenation, in Kusto form.
Comments closedChris Webb hits the turbo button:
Do you have a a large dataset in Power BI Premium or Premium Per User? Do you have more than six tables that take a significant amount of time to refresh? If so, you may be able to speed up the performance of your dataset’s refresh by increasing the number of tables that are refreshed in parallel, using a feature that was released in August 2022 but which you may have missed.
Click through for that tip.
Comments closedIt’s time to look back at the 155th blog party. I was the host this month, asking about Dynamic SQL. I got quite a few responses, which I’ve gone through and summarized below. If I’ve missed someone, please ping me.
Read on for a variety of thoughts on the topic.
Comments closedRyan Majidimehr has a short list of updates for Azure Synapse Analytics but it includes a big one:
Azure Synapse Analytics provides built-in R support for Apache Spark. As part of this, data scientists can leverage Azure Synapse Analytics notebooks to write and run their R code. This also includes support for SparkR and SparklyR, which allows users to interact with Spark using familiar Spark or R interfaces. To learn more read the official how-to Use R for Apache Spark with Azure Synapse Analytics (Preview).
That it took this long for R support was a bit weird, but I’m glad it’s there now.
Comments closedMeagan Longoria explains an important part of source control repositories:
I’ve seen a few people start Azure Data Factory (ADF) projects assuming that we would have one source control repo per environment, meaning that you would attach a Git repo to Dev, and another Git repo to Test and another to Prod.
Microsoft recommends against this, saying:
Read on for the citation as well as the practical reason why we don’t want multiple repos. This is true not only for Azure Data Factory but for every development project. You have one repository with branches. Certain branches represent checkpoints where code goes out to a specific environment via use of a release tool (e.g., Azure DevOps release pipelines, GitHub actions, etc.).
Comments closed