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.
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.
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.
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.
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.
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.
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.