A Fine Slice Of SQL Server
Mike Cisneros lays out the argument:
In school, I was taught that you should center-align and capitalize the first letters of words in titles. I’ve noticed, though, that storytelling with data charts only capitalize the first word in the chart title, use ALL CAPS for the axis titles, and don’t center-align anything. Why?
Title casing is a really hard habit for me to break. I understand the “why” behind this, but it’s a change I’m unlikely to make anytime soon.
Comments closedReza Rad gives us the lowdown on sparklines:
You can, of course, achieve the same thing using a line chart. You have to multiply it for each of the categories (you can do that in Power BI using small multiples). However, if you have many categories, then a small multiple might now show a nice view. that is why Sparkline can be helpful.
Sparklines are normally with minimal information. Their X-axis is a trend based on date (or something similar), but the axis is hidden because of minimal space. You can use the sparkline to understand the trend, the highest, the lowest, the starting and the ending point, etc. Because of their minimal nature, Sparklines are not used for a very detailed analysis. Instead, they are used to understand the trend of different categories over time in a high-level view.
Click through to see how you can add a sparkline to a table or matrix.
Comments closedJoe Obbish shows the difference between two functions:
There’s a lot of guidance out there that states that TRY_CAST is a faster, more modern version of TRY_PARSE and that TRY_PARSE should only be used if you need to set the optional culture parameter. However, the two functions can return different results in some cases, even without the culture parameter.
That guidance is blatantly wrong. TRY_CAST() and TRY_PARSE() both came out in SQL Server 2012. TRY_PARSE() uses .NET to perform parsing, which is going to have some edge case differences, especially around cultures and localization. TRY_CAST() is CAST() in an error-safe wrapper. If anything, TRY_CAST() is the “old” version and TRY_PARSE() the “new” version, with scare quotes in place because they both came out at the same time.
Both of them are useful, though I do agree with Joe’s advice of avoiding TRY_PARSE(), at least for larger datasets. If you’re parsing a single date or a small table of dates, TRY_PARSE() does an excellent job because TRY_PARSE('13/01/2019' AS DATE USING 'fr-fr') is not something you can easily do with TRY_CAST() in a US locale.
Andy Leonard has an announcement:
The very first data integration / data engineering framework I ever wrote was for Data Transformation Services, or DTS. The DTS framework had one job: manage connections. I don’t recall all the details, but I remember DTS included a task that allowed packages to retrieve settings from INI files. INI files are key-value files, so I simply added entries with identical keys and different values – values that matched connection strings for each lifecycle tier – and placed each version of the INI file in the same location on every server in the lifecycle.
The next framework I wrote was for SSIS. I stored metadata in tables – including connections metadata – and created a concept I called an SSIS Application. An SSIS application is, according to my definition, a “collection of SSIS packages that execute in a pre-determined order.”
The SSIS Framework File Community Edition is very similar to this first framework, except for the connections management.
Click through to learn more about the SSIS Framework File Community Edition and check it out.
Comments closedBruno Gabrielli connects Azure Montor to SQL Server Audit:
Today I am going to cover an interesting aspect on how to capture security audit events from both Azure and non-Azure SQL Server machines. Most of you probably know that SQL Server is capable of auditing security related information, such as access to a given database, record creation or deletion, configuration change and so on) according to the Audit configuration applied to a given instance or database.
In this post, we will not dig into SQL Server Audit configuration or capability. We will rather explore the steps and configurations necessary to collect data using Azure Monitor.
Read on for the process. You will need the appropriate agent for this, but that agent doesn’t necessitate that your machine be in Azure.
Comments closedNiko Neugebauer has a pair of connectivity tests for us. First up is failover group connectivity:
When you set up a failover group between primary and secondary SQL Managed Instances in two different regions, each instance is isolated using an independent virtual network. Replication traffic needs to be allowed between these VNets.
To allow this kind of traffic, one of the prerequisites is:
– “You need to set up your Network Security Groups (NSG) such that ports 5022 and the range 11000-11999 are open inbound and outbound for connections from the subnet of the other managed instance. This is to allow replication traffic between the instances.”
Click through for a SQL Agent job script which helps with the test. Meanwhile, you can also test TCP connectivity from a managed instance:
In this post we shall focus on helping you determining the TCP connectivity from SQL Managed Instance against a given endpoint and port of your choice.
If you are interested in other posts on how-to discover different aspects of SQL MI – please visit the http://aka.ms/sqlmi-howto, which serves as a placeholder for the series.
There are scenarios where it would be nice to be able to test if a SQL Managed Instance can reach some “external” endpoints, like Azure Storage as an example.
Check out both posts.
Comments closed