Shaun J. Stuart notes that database mail apparently still requires .NET Framework 3.5:
However, I did run into one issue later on regarding database mail. I was able to configure it correctly and was even able to send a test email through SSMS without any errors. Unfortunately, the email was never delivered. Additionally, the database mail logs did not show database mail starting or attempting to send the message. I checked with my Exchange administrator and he said he never saw the SQL Server connecting to the mail server.
A check of the database mail table in msdb (sysmail_allitems) showed my messages sitting there with a status of Unsent.
After troubleshooting for a couple of hours and getting nowhere, we installed in the .Net Framework 3.5 and suddenly database mail started working.
This, hopefully, is a bug. But not getting e-mail alerts you’re expecting to receive can be a scary scenario.
Cody Konior shows us how to create a SQL Server bulk insert format file using Powershell:
Don’t forget there are a few minor security considerations:
- Your login needs Administer Bulk Operations permission.
- Your AD account needs access to the file (and possibly delegation enabled for remote shares)
- Or if using an SQL login the database engine service account needs access to the file.
Anyway now that we have the data in table format without worrying about ordering or duplicate column names, we can much more easily manipulate it and store it into the database.
I remember creating a couple of these by hand, and that was no fun. I never created enough to get the hang of the syntax or to want to automate the process, but at least I know where to look if I ever have to do this again.
The MDX keywords in a cube script were not properly changing colors in the SQL Serve Data Tools (SSDT) Preview version for Visual Studio 2015. (14.0.60316.0). (See my previous post on this problem here.)
The different keyword colors make it easier to write, organize and read an MDX script inside a cube.
Looks like they squashed that bug.
Grant Fritchey shows how to build Elastic Query views to obscure underlying table names:
Creating a view, or any other query, that joins across databases using Elastic Query works just fine. However, if you want to mask things using a view, you might need to get a little creative in how you implement Elastic Query. The good news is, Elastic Query is somewhat, shall we say, elastic in how you set it up. More so than it immediately appears.
Interesting.
Slava Murygin has updated his script to include memory-optimized and temporal tables:
There is also new column called “Temporal”. It indicates if a table is System Versioned or it is Historical repository. Row_Count number for Historical repository indicates number of changes done to the main table. That option is applicable only for SQL Server 2016.
I’ve updated only “Ctrl-F1” button, which returns list of tables within a database. Here is the link to the full script archive:https://drive.google.com/open?id=0B5yWoyX1eEWqZ3FJUnNHZm80bzQ
Check out his script.
Bill Anton is sharing data from a March survey:
Instead of digging into the data and spoon feeding you the results, I’ve created a Power Pivot model (download link) that you can use to explore for yourself. I’d also like to invite you to share any interesting insights you uncover in the comments section and/or provide feedback on this little survey experiment (missing questions, phrasing, etc).
Happy digging.
Joey D’Antoni has additional information on licensing for SQL Server 2016:
SQL Server 2016 launched last week to great reviews and with a ton of great new features. I have been working with this version for well over a year now and extremely happy to see it hit RTM and be broadly adopted. So as DBAs it always sucks when you get excited about new features, only to find out the price changed, or vendor “O” made that feature a cost option. So what’s new with SQL Server 2016 licensing? (you won’t this as a session title at any upcoming SQL Server events). Well first the good news—SQL Server 2016 is the same price and 2012 and 2014 (roughly $6800 core for Enterprise Edition). That’s definitely good news—Microsoft gave us a bunch of new functionality and didn’t raise the price. Additionally, if you see my below post on what is in Standard Edition, they added a lot of functionality there, too.
But we know finance and marketing employees have jobs to do as well, and there is no way they were letting a major version release happen without some changes. So let’s take a look at the one’s Denny Cherry (b|t) and I could glean out of the licensing guide. Please download and read for yourself.
There are a couple of interesting nuances that you’ll want to read up on.
Regis Baccaro shows how to change the user language in SSRS 2016:
Changing it to Spanish and refreshing the browser changed the SSRS user language to Spanish without me having to add a language at all.
To change the user language of SSRS 2016 you need only to change the Formatting Region setting from the control panel – nothing else !
The issue I tend to have with this is that different tools tend to behave differently when you start changing the format settings. I recall Excel being particularly finicky about it.
Glenn Berry has a new update of his diagnostic queries, focused around SQL Server 2014 and 2016:
This month, I have several improvements in the SQL Server 2014 and 2016 sets, along with additional comments and documentation in the SQL Server 2012, 2014 and 2016 sets. One new feature is a series of six dashes after each query to make them easier to parse by people who use PowerShell to run the queries and collect the results. I have gotten quite a bit of interest about making a special version of these queries for SQL Database in Microsoft Azure. So, I will be doing that pretty soon.
If you don’t already use Glenn’s queries, I highly recommend them as a starting point in tracking down issues.
Manoj Pandey notes that Polybase has a row size limit:
With the error description its quiet evident that the External tables does not support row size more than 32768 bytes. But still I take a look online and found in Azure Documentation that this is a limitation right now with Polybase. The Azure document mentions:
Wide rows support is not supported yet, “If you are using Polybase to load your tables, define your tables so that the maximum possible row size, including the full length of variable length columns, does not exceed 32,767 bytes. While you can define a row with variable length data that can exceed this figure, and load rows with BCP, you will not be be able to use Polybase to load this data quite yet. Polybase support for wide rows will be added soon. Also, try to limit the size of your variable length columns for even better throughput for running queries.”
You can still use varchar(max) and nvarchar(max) for data types (unlike the Hive provider, which has a strict limit of 8000 characters for a single column) but can’t break that 32K mark.
Kevin Feasel
2016-06-10
Administration