The point of these functions is to make it easier to construct a date, or datetime, or datetime2 variable, when you know the individual parts.
DATEFROMPARTS()takes three arguments:
day, and returns a
datevalue. So, for example,
SELECT DATEFROMPARTS(2016,7,6);would yield the date
Read on for a comparison of this function against about a dozen other methods of building dates from components.
Two important criteria must be met to allow parallel execution of an INSERT … SELECT statement.
The database compatibility level must be 130. Execute “SELECT name, compatibility_level FROM sys.databases” to determine the compability level of your database, and if it is not 130, execute “ALTER DATABASE <MyDB> SET COMPATIBILITY_LEVEL = 130” to set it to 130. Changing the compatibility level of a database influences some behavior changes. You should test and ensure that your overall application works well with the new compatibility level.
Must use the TABLOCK hint with the INSERT … SELECT statement. For example: INSERT INTO table_1 WITH (TABLOCK) SELECT * FROM table_2.
This is a limited use case, but it does sound very useful for large staging table loads or backfills when you can control table access.
When you create VM from a captured image, the drive letters for data disks may not preserved. For example if you have system database files on E: drive, it may get swapped to H: drive. If this is the case, SQL Server can’t find system database files and will not start. If the driver letter mismatch occurs on user database files, then the user databases will not recover. After VM is created, you just need to go to disk management to change the drive letters to match your original configuration.
Read the whole thing if you’re thinking about copying your on-premise server to an Azure VM.
The June release of Power BI Desktop has what seems to be a fairly unremarkable new feature in that it allows you to add descriptions to each step in a query in the Query Editor window. However the implementation turns out to be a lot more interesting than you might expect: the step descriptions become comments in the M code, and even better if you write M code in the Advanced Editor window your comments appear as descriptions in the Applied Steps pane.
I think this is a smart move, although it does mean that you have to keep those comments up to date…
An AstTableNode requires a schema to be valid, which is the only information that we can’t get from the AstFlatFileFormatNode so we’re defining a variable called UseSchema and pass it to our ToAstTableNode extension method.
But… how does that extension method work? MUCH easier than you might think.
Writing an extension method in C# isn’t tough either.
This code works, but if you have dozens of years, it gets messy writing those case statements and you’re a bit more likely to make a mistake when refactoring code. Here’s a simpler version using CROSS APPLY:
(2013, [Qty2013], [Val2013]),
(2014, [Qty2014], [Val2014]),
(2015, [Qty2015], [Val2015])
], Quantity, [Value]);
It’s a little easier to read than the other version, and adding additional years is pretty straightforward. That makes for a great tip when you’re trying to refactor poorly-thought-out tables or bring into your system potentially well-thought-out flat files.
APPLY is an elegant solution to so many different classes of problem.
This Biml declares an AstFlatFileFormatNode named ffformat and sets it to the FileFormat named “FFCM Provider Data” found the RootNode’s FileFormats collection. I next loop through each column in the ffformat AstFlatFileFormatNode object. I use Biml to generate the <Column> object, replacing the spaces with an empty string for the Name attribute. The results in Mist appear as shown below
I loved the “I had 5 minutes, so I decided to fix it with Biml” line. Both funny and true.
Now, take a look at the KPI visual. What happened? First, you should notice a trend line on the KPI that depicts Sales Amount for each month. This is cool and a great feature of the visual, but wait. Why doesn’t the Indicator value and the goal match the values in the Card? Now I see the confusion.
I appreciate that Patrick put in several embedded reports to show us exactly what’s going on.
In addition to the performance reasons, there are other reasons not to use nested views. Supporting and maintaining a nested views can be a nightmare. If there is an issue with the accuracy of the data, finding the problem is just that much harder. And what about when you go to fix the problem? Then you need to test all of the places the view is called. I worked with some code recently where a view was created on a set of data just to create 3 new values based up 3 case statements. That view was nested many levels below where the field was actually called. I know people from a development background look at nested views as modular development. Don’t. TSQL is not the same as object oriented code.
Read the whole thing. She also has helpful links digging further into the topic.
Always Encrypted uses two types of cryptographic keys: column encryption keys (CEKs) and column master keys (CMKs). A column encryption key is used to encrypt data in an encrypted column. A column master key is a key-protecting key that encrypts one or more column encryption keys. A column master key is stored in a key store that is external the database and is accessible to a client application, for example Windows Certificate Store or Azure Key Vault. The database server does not store the keys of either type in plaintext – it only contains metadata about the keys in column master key and column encryption key metadata objects.
Given that they’re supporting database projects, I wonder if Integration Services is far behind.