Microsoft & Red Hat Sittin’ In A Tree

Microsoft and Red Hat have joined together to support Linux in Azure.

Customers can already run Linux on Azure, but the new partnership will expand support for running so-called “hybrid clouds,” in which applications may exist in both private data centers and on public cloud services. More significantly, Microsoft and Red Hat support teams will work together from the same facilities to support Red Hat customers using Azure. Microsoft vice president of cloud and enterprise Scott Guthrie said during a webcast today that this is the first time that he knows of that Microsoft has “co-located” support teams with another company.

The deal is the latest example of Microsoft playing nice with a former rival. “When we started [Red Hat Enterprise Linux] I never would have thought we’d do this,” Red Hat president of product and technology Paul Cormier said during the webcast.

Free speculation with no evidence:  at some point, Microsoft will offer SQL Server on Linux.  My guess is 3-5 years from now, but other co-speculators have suggested maybe even as soon as 18 months.  Whatever the case, I’ll be a happy man when I can run SSMS in Linux.

Nested Transactions Aren’t

Friends don’t let friends nest transactions:

Before getting into the details, I need to make one thing clear. Nested transactions are a lie. They do not exist in SQL Server.

This is part 1 of a three-part series by Gail Shaw.  Read the whole thing.  Also read Paul Randal:

Nested transactions do not actually behave the way the syntax would have you believe. I have no idea why they were coded this way in SQL Server – all I can think of is someone from the dim and distant past is continually thumbing their nose at the SQL Server community and going “ha – fooled you!!”.

Nested transactions are somebody’s attempt at trolling.  They succeeded.

Goodbye 32-Bit SQL

32-bit SQL Server is gone; long live 64-bit SQL Server:

Does this mean there will be no 32-bit version of SQL Server 2016? They may make some desktop version; I don’t know nor have I been following. But as a Server product? RIP, and good riddance.

So you can thank (or damn) me for this one. Me, I’m going to celebrate. Where’s my bottle of Coca Cola with real sugar?

Allan Hirt, I thank you.  I have one 32-bit device left:  it’s a cheap tablet.  Let’s not wait until 2038 to get rid of x86.

Azure SQL DB Trace Flags

Grant Fritchey shows us that Azure SQL Database does not support trace flags at this time:

Bad news. The error message is the same.

Working within Azure SQL Database, trace flags are not a part of your tool set.

Everything with Azure needs a timestamp.  Come back in a year and this may be different.

Clustered Indexes Do Not Guarantee Physical Order

Gail Shaw on how clustered indexes do not guarantee physical order:

Do indexes (clustered or non-clustered) define the physical storage order of the rows?

No, absolutely not.

What indexes do is provide a logical ordering, a collection of pointers, that allow the storage engine to retrieve data from an index ordered by the index key, but that’s logical ordering, it specified nothing regarding the physical ordering.

Read the whole thing.

Welcome To Curated SQL

Curated SQL is a simple premise:  act as a clearinghouse for high-quality SQL Server material.  Basically, we want to distill the tremendous number of articles and blog posts and make it easy for you to find the best of the web.  This is a curated site, so all posts are lovingly hand-crafted, with nary a bot to be found.

If you want to learn more, read our About page.  Also follow us on Twitter.  And then, scroll up and enjoy the show.

Table Migration In SSDT

Ed Elliott shows us how to use pre-deployment and post-deployment scripts to migrate table data when the tables change:

You sometimes want to do things like split a table into two or move a column into another table and when you use SSDT or the compare / merge type of deployments it can be hard to migrate the data in a single deploy as you can’t insert the data into a table that doesn’t exist and you can’t drop the data before it has bee migrated. To fix this we can use pre/post deploy scripts in SSDT. The overall process is:

  • Pre-Deploy Script, check for column to be migrated

  • Save data in new table not in SSDT (you could have it in SSDT if you use it for multiple releases etc)

  • Let SSDT drop the column and create the new one – you will need to have the option set allow data loss on incremental deployments

  • In the post-deploy copyw the data to the new table

Using separate migration tables is an interesting solution to an old problem.

Categories

April 2017
MTWTFSS
« Mar  
 12
3456789
10111213141516
17181920212223
24252627282930