Skip to content

MS14-044–Security Alert for SQL Server

I just saw this, but you should be aware. There’s a potential Denial of Service/Elevation of Privilege bug in SQL Server. Here’s the bulletin:


There are QFE and GDR patches for versions since 2008, but you need to read carefully to determine which one to install on your systems.

The Brittleness of Replication

I’ve used replication for years in different positions. I first discovered it in SQL Server 6.5, using it to simulate a queuing system to keep two disparate applications in sync without requiring transactions between the applications and causing errors. As handy as replication was, it was also brittle. Small things would sometimes break replication and the quickest way to repair the system was to drop replication and re-initialize it. Fortunately my data was small in size.

As I’ve watched replication grow through the years, I’ve been happy to see enhancements, like the ability to replicate schema changes to objects contained in articles. However I’ve been disappointed that the tooling has barely improved and the brittle nature of the process has not been addressed.

It seems that as SQL Server grows, we find more and more features and subsystems that are being managed like replication. They get built and then languish with few resources devoted to improving their tooling and robustness. Service Broker, spatial data, and more are examples of features that were introduced, but have received little attention in newer versions.

I have to believe there are developers at Microsoft that would love to make the product better. I understand the need for new features, and continuing sales, but devoting a percentage of time to improving existing features, regardless of the Connect votes or marketing wishes, would help make the platform that much better for everyone.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.2MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at

T-SQL Tuesday #57–SQL Family and Community

TSQL2sDay150x150It’s T-SQL Tuesday time again. After missing two months with my sabbatical, I’m back.

The topic this month is hosted by Jeffrey Verheul and it is SQL Family and Community. That’s a topic near and dear to my heart, and I’m glad to participate this month. Jeffrey asks: How do you feel about SQL Family? Did they help you, or did you help someone in the SQL Family?

You can participate as well. Setup a blog, watch for the announcement each month (it varies, so search or follow #Tsql2sday on twitter) and then write a post on the second Tuesday of the month.

Contact Adam Machanic (Blog | @AdamMachanic) if you’d like to host. I also maintain a list of topics.

SQL Family and Community

I have a couple thoughts about SQL Family to tell. There are many of them I’ve been a part of, and my apologies if you think I should have chosen another one, but I have to choose. The SQL Server community, the people in it, are just amazing. It’s a closer, and tighter, and friendlier community than I’ve ever been a part of.

It really is close to family.


A few years ago I was on a running streak. I ran at least a mile a day for over 1500 days. I actually retired the streak, but the milestone that might mean the most was day 1000.

I wrote a bit about the day, where I got a great note from work, and my family ran with me. I got lots of congratulations from the community, as there are quite a few runners who work with SQL Server, and many others who helped support and inspire me to keep going. However the big news came from a phone call.

Jes Borland (twitter, blog, BrentOzar Unlimited), whom I had never met at the time, contacted me and asked me for my phone number. She called and said that she was working on a gift for me: new shoes. With help from Red Gate, Jes arranged for a custom pair of Nike running shoes to be sent to me, customized with “1000” on the rear.

I still have those shoes, though the 1000 is coming off. I even wear them on occasion. Every time I look at them, I remember that phone call, and the really, really special gesture that Jes made.

I was touched, and I’ve been lucky enough to not only meet Jes and develop a friendship, but also run with her in Seattle, Fargo, and probably a few other places.

The SQLFamily Bond

The one thing that seems to happen over and over again in the SQL Server professional community is that people care about each other. They help each other, and they respect each other. They pull together, working to help everyone be better.

Certainly people bicker. They get upset, and they disagree. However, it seems overall that we really are closer to an extended family, giving of ourselves to treat others well when we don’t have to. SQL Saturday is a great example of that, with tremendous growth in seven years, with events where people seem to be more well behaved toward each other than at many other events.

I see people offering others rides to and from places. I know community members that offer their homes to others to give them a place to stay, or will split a hotel room. We create opportunities to bond and relax with each other outside of events. #SQLRun, #SQLSki, #SQLCruise, #SQLKaraoke and more exist in casual, friendly ways that I haven’t run into when I’ve dealt with other technologies.

I don’t know that why the SQL Server community is different, but I’ve never seen another niche of professionals to whom I’d apply the word “family.”

Do We Care?

Today’s editorial at SQLServerCental is entitled: We Don’t Care about Data and IT Security. It’s by Brian Kelley (author, blog, twitter), and I think it’s worth a few minutes of your time to read.

It’s aimed more at executives, and certainly talks about the disconnect between actions and words. People talk about security being important, but rarely seem to make fundamental changes that might improve things.

I tend to agree, though I also think it’s not as cut and dried, and often we have a disconnect in what we really want or need from security. Do we need chip-and-pin cards v our signature ones? It’s arguable that the former are more secure, but there have been incidents, and without a doubt the large scale of the US credit card market would mean more and more attacks. There is an argument that the devil we know is better than the one we don’t.

However there certainly are not great coding practices in many organizations. I think we far, far too often do not train or show new developers how to code more securely. We also don’t require older developers to change their habits to implement new techniques that limit issues. We also don’t bother to review code that consultants write and require security. It’s far too easy to “just get it into production” for many people.

Overall, I tend to agree with Schneier and Brian in that we need to rethink security in our languages, but also fundamentally in how computer systems work. We also need a culture of security, something that won’t take place until we mature as a digital civilization.

Data is Not Always Enough

As data professionals, our jobs deal with ensuring that there is data available, accurate, and relevant to the organizations in which we work. However we often go beyond the simple maintenance, gathering, and manipulation of data to help our clients and customers understand the information contained in our systems. In many of my positions, whether as developer or DBA, I’ve been tasked with working closely with business people to make decisions based on data.

I’ve always been of the opinion that more data is better, though I certainly understand the problems of Big Data and the potential to reveal false patterns or overwhelm systems with conflicting information. The better I understand the domain, and the better educated the business analysts are, the better we can work to extract information from databases.

However that’s not always enough to help an organization act. I read an interesting piece this week on data in sports, which talks about one of the NHL team’s managers using data to make decisions on how to restructure his team. It’s interesting to see that additional data gives the general manager more insight, and leads him towards a decision, but the rest of the organization can’t follow through. In this case it’s a matter of money, but resources constrain our efforts in many decisions. I think this is a place where more flexible, and perhaps more in-depth, BI-type analysis of what-if scenarios can be more helpful.

The other piece that caught my eye had to do with real estate, and housing prices, with the author bemoaning the lack of data in determining the value of a house. It’s interesting, but to me, it’s flawed. More data won’t help because houses aren’t like many other commodities. One house is not fungible with another one, and the market is both fast moving, and inherently full of friction. We rarely buy a house without visiting it, a task that consumes time, and slows the movement of information through the system. I’m as frustrated as the author, but I don’t know that more data would help in this case.

Data is important, and it should be a part of our decisions, but we should remember that data isn’t necessarily going to make the decision for us. We need to be ready to incorporate our own knowledge and judgment into a data set to help us decide on a course of action.

Steve Jones


Final Project–Sabbatical

My company, Red Gate software, has given me a 6 week sabbatical. I’m documenting the time with all the posts under a tag if you want to follow along. The sabbatical is over, but I’m still catching up on things.

Thursday, July 31. Final day of class for this semester. I knew I was close, and wasn’t too worried. I got to school early to miss traffic and was working on my laptop as a few other students walked by around 5. We chatted for a minute and they were heading in to finish. Around 5:40, I started to feel pressure and closed the laptop and got started.

Most of my table was together, dry fit, but I wanted to pin it, and also needed to clean up shoulders. I walked in early and sharpened a chisel to begin work on the shoulders. Sharp tools make a big difference.

Photo Jul 31, 5 58 38 PM

I managed to clean things up so they fit well. Looking back, I should have checked lengths as I ended up shortening a few shoulders more than I wanted, meaning two aprons were different lengths. However I had things fitting well.

Next the instructor showed us how to pin the joints, and gave us the option of pins or glue. He also showed us glue, but I wanted to avoid that. I went back to my bench and got everything fitting well and then started to drill.

Things went quick on the drill press, though once again, I learned something. Good to have an instructor there to help guide and give hints. I might have drilled the wrong edge, which a few students did. Pay attention to the details.

The plan was two pins on one side (each leg) and one pin on the other. I marked carefully and then punched them out. Here’s the pattern. Roughly 3/4” from the top and bottom of the tenon (not apron) and then the one I between those.

Photo Jul 31, 7 25 34 PM

With those all cut, and then offset (1/16” holes in the tenons, I was ready to pin. Here’s the first one going on. A dowel, sharpened on one end, driven through.

Photo Jul 31, 8 20 56 PM

Once through, I had to cut them off.

Photo Jul 31, 8 29 53 PM

The saws don’t get that close. I did borrow a flush cut saw from one guy, but didn’t want to keep using it, so I moved on to the old fashioned method.

Photo Jul 31, 8 33 44 PM

It’s slow, and I learned to put the direction of the chisel perpendicular to the grain, and then saw sideways to get things cut. Once I had them down, they were pretty flush.

Photo Jul 31, 8 27 28 PM

Next I needed to attach ledgers for the top. Glued on and then stapled to hold them. It seems like less hand tools over time, though another instructor said this is hard in the summer. Things are shortened up, moving at almost twice the speed of the fall/spring semesters.

Photo Jul 31, 8 11 06 PM

I continued on, pounding in the long sides with two pins each.

Photo Jul 31, 8 39 59 PM

Since this was final assembly, I ended up putting in four, then cutting off and chiseling all four at once. The a repeat on the other side.

Photo Jul 31, 8 40 45 PM

With all four sides on, and almost 9:00, I measured and then put the top down with the legs on and screwed things down. This is where I realized that the top wasn’t square, with 1/16” off on two sides. A lesson, but it’s hard to tell with the table that it’s not square. Another lesson.

Photo Jul 31, 9 04 38 PM

The only screws (and glue) are holding these ledgers to the aprons and then the top on. Overall, a success.

I set it down in front of the instructor at 9:15, 15 minutes early. Close, but better than most. I was first done, though 3-4 were done in the next few minutes, so not bad. A few people were still getting legs tapered or tops beveled.

To be fair, I didn’t use a plane for the bevel, which a few people did, but I wasn’t overly concerned. I’m confident I can, and I was running short of time with travel for work. I also learned a bit about how I might bevel things on the table saw.

Photo Jul 31, 9 27 07 PM

I set the table on the floor, put a glue bottle on it and it didn’t roll. Considering I hadn’t double checked leg measurements, that’s a bit of a success.

Final project done, though I need to sand and finish it this weekend with some poly.

Speaking at SQL Saturday #304–Indianapolis

indy304Next weekend is SQL Saturday #304 in Indianapolis, a milestone for me. It’s the first Indy SQL Saturday I’m speaking at, though not the first one they’ve held. I’ve been to the Indy Tech Fest, but that was years ago and I’m looking forward to going back.

It’s also the first 300-ish event for me. I’ll be at #300 in Kansas City in September, but as it sometimes goes, #304 is happening before that milestone.

This looks like another great event, with speakers coming from all over. The schedule has Allen White, Brian Davis, and Erin Stellato coming from Cleveland. Joey D’Antoni from Philadelphia, Kevin Boles from Alabama, Rob Volk from Atlanta, Tamera Clark from Tennessee, and more. I see amazing sessions on Azure, T-SQL, execution plans, extended events, XML, Hekaton, and more. The biggest challenge will be choosing between sessions.

I’ll be delivering my branding session, at 9:15, so hopefully I can convince a few of you to network and brand during the day.

If you are anywhere near Indianapolis, which means Louisville, Cincinnati, Dayton, even Chicago or St Louis, I hope you make the drive and come attend.

And please be sure to stop and say hi and shake my hand. It’s always a pleasure.



From the Stack Exchange chat.

A late night–sabbatical catch up

My company, Red Gate software, has given me a 6 week sabbatical. I’m documenting the time with all the posts under a tag if you want to follow along. The sabbatical is over, but I’m still catching up on things.

I took an extra day in the wood lab last night. The instructor offered to show up Wed night, with all projects and work due Thur, and I wasn’t the only one that needed the time. Almost the entire class was there, and it was fairly quiet with no other students or instructors working.

With my piles of parts close, the first thing I needed to do was cut tenons. I’ve done this before, by hand, with limited success. However since time is short this semester, we were given permission to use the bandsaw (and a little instruction).

I first marked things up.

Photo Jul 29, 5 47 21 PM

As with the mortises, I was thinking I could mark one board and use the setup for others. However when I showed the TA, he saw some problems. First, I needed to center the tenon. That messed up my reveal, but I could always plane the board to fix that. Then he noticed that when I’d cut left and right hand mortises, my setup was slightly off, so that they are slightly (1/64”) low on one side. Not a huge deal, but it means I need to account for R and L tenons differently.

So back to marking, spending the better part of an hour marking all 8 sides of the 4 boards, in stages to separate right from left. With that done, I turned to the bandsaw to cut the tenons.

Photo Jul 30, 8 14 15 PM

I went a little fat, having had experience with too thin. I ended up too fat, and spent most of the night fussing to get thickness, and then height, to the correct settings. Once they were cut, I felt like I was making progress, but little did I know.

Photo Jul 30, 7 53 50 PM

I went very slow on the router plane, making some passes that didn’t cut anything or generated dust. However I wanted a tight fit. Things were tight on the right tenons, but later I had to come back to this to thin a couple left ones. However I had tight fits all around.

Photo Jul 30, 7 53 44 PM

Once those were done, I re-marked, and shaved off the upper part of the tenon. Things still seemed to fit well, and I had a decision to make. The bottom shoulder was about 1/16”-3/32”, depending on left or right. I could lengthen the mortises and have no shoulder (tempting) or cut a small one. I opted to cut a small one. As much as I like the mortiser, it takes time to setup and at this point, I’d blown 2 of my 3 hours and wasn’t terribly close to having a single joint. I still knew I’d have shoulder work.

I lightly trimmed the bottoms, and as I worked on squaring the shoulders to the joint, I went back to the bandsaw a few times for small trims. I was trying to be careful, but also feeling pressure. Never a good combination.

Once things were cut, and thinned, I test fitted them together. The right hand ones seemed to do OK.

Photo Jul 30, 8 26 05 PM

You can’t see it well, but the shoulders on most were slightly off to way off. I spent about 15 minutes trying to get one to fit, before I got too frustrated and decided to work on them in the order of the closest to fitting to least.

Photo Jul 30, 8 26 00 PM

Back and forth to the vise, using a chisel to square, and then fit again. I’d hit the bandsaw for the ones that were way off to save time. Chiseling is satisfying, but slloooooowwwww and things are due Thursday.

When I had a good fit, with almost no gap, I’d mark the back of the board. I got the short aprons (sides) done first and I could put two legs on an apron and felt good. The long sides were harder, and 3:15 into extra lab time, people were cleaning up. I decided to try a test fit and see where I was.

Photo Jul 30, 9 42 06 PM

Things went together. I was amazed, and also somewhat proud. After all, I’d started with a pile of rough lumber board. I dropped the top on, just to see.

Photo Jul 30, 9 42 21 PM

It looks good. I actually built a piece of furniture that doesn’t need glue or screws, and looks decent.

Photo Jul 30, 9 42 27 PM

There are three bad gaps on the long aprons (front/back) that I need to fix tonight. I also need to run the bottom of the top (if that makes sense) through the planer to thin it and shorten my bevel. A little long for the side of the bottom.

I’ve also got the dimensions slightly smaller than I’d like, so I have to decide if it’s worth trying to shorten aprons slightly from a design aspect. Probably won’t do that, but it’s something I’ll think about.

Hoping to get to pin it with dowels tonight, but if I don’t, I’ll drill and add faux pins for decoration.

Monitoring for Non Existent Events

I was catching up on work recently, reading the third installment of The 5 Worst Days in a DBA’s life, starring The DBA Team. Someone had asked me if I enjoyed having Paul Randal (b | t) of SQLskills join them team. The piece had been edited and published while I was gone, and I hadn’t had a chance to immerse myself in the adventure. I was anxious too read how Paul helped save the day.

It was a fun read, but one quote in the piece struck me. “A job that runs long or doesn’t run at all can sting just as bad as one that fails.” That’s a quote from my character showcasing a situation that few people actually think about. However jobs that don’t run or don’t finish are situations that DBAs should be monitoring for.

So many of us adopt a set-it-and-forget-it mentality with our jobs. We assume that things will work, or fail, as we set them up. However it’s easy to forget that there are other states we might find ourselves or our systems in that can cause issues.

Monitoring is critical to any well run system, but monitoring needs to be set up well. If we require that certain jobs run, we need to not only check for success or failure, but if the job has actually run and completed. It’s easy to accidentally disable the wrong job and not notice. It’s also entirely possible that a job gets stuck and doesn’t complete.

If you’re not watching for those other states, you might find yourself in a situation where you don’t have backups and your job is on the line. However you probably won’t have The DBA Team to call on.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.2MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at


Get every new post delivered to your Inbox.

Join 4,612 other followers