Within a couple of days of each other, both Andy Leonard (@AndyLeonard) and Paul Randal (@PaulRandal) tweeted about possible job opportunities which would entail working with them. Here they are  

This got me to thinking about working with/for high caliber folks. Andy and Paul are both SQL Server MVPs. Andy is well-known for his SSIS prowess and bringing design patterns to solutions (translation: he is a true application / enterprise architect). Paul? He only had a hand in writing key aspects of the product and managing other folks who did likewise. Needless to say, working with these two should be like drinking from the firehose, to borrow an expression. I know some probably saw one or both of the opportunities and went, "Dream job!" while others went, "I couldn't handle it!" And I'm sure there were reactions that varied somewhere in between these two extreme views. And as I was thinking, my mind wandered off to Mike Walsh, who used to work for Andy Kelly. Mike credits Andy with teaching him how to be a professional caliber DBA.

I haven't had the pleasure of working for such high caliber folks with respect to SQL Server, but I have in ministry. One of my mentors is Dr. Tom Fillinger, and the years I spent working under him as a children's minister were challenging (in the best way possible). In the SQL Server world it's about knowing your craft well. In ministry it's the same thing. I knew that because that's common sense. But how exactly do you approach ministry, how do you ensure that you do so with standards and expectations, and how do you measure how you're doing, especially when talking about an age group (bed babies through elementary school) where obvious growth tends to show only much later in life, were areas we focused on and dug into. There was also the constant reminder that ministry wasn't just about numbers and results. Yes, those are important. But ministry is about people. It's about caring for them and loving them and encouraging them and finding ways to reach them. And ministry is about what you believe. You have to stay true to that. And while all of that is common sense stuff, it's the HOW that Tom taught me that has been so key to my development in ministry. Quite simply, his example has stood as a constant challenge to reach for. That example, by the way, almost discouraged me from signing on in children's ministry. I could tell right away that Tom was one of those high caliber folks. And so naturally the thoughts of, "Can I do this?" and "Will I survive his expectations?" came up. But I was sure of my calling and sure that this is what I wanted to do. So I became children's minister, grew tremendously, and served in that role until I felt the calling to move to a different challenge.

When it comes to IT, things aren't very different. Most folks, when faced with the prospect of working with high caliber folks, start to doubt. That's a natural response. In Mike's case, he didn't know what he was getting into with Andy Kelly (and here Andy would likely quip, "Does anyone?"). But most folks who would have seen Paul's or Andy Leonard's tweets do know. And it can be very easy to talk oneself out of trying because of the magnitude of the people involved. If that sounds like you, stop it. Working for Tom was the most challenging time in ministry I had at that point in my life. It grew me tremendously to be able to take on youth ministry. When I left the Air Force, that was what I wanted to do: be a youth minister. Now, having the experience of almost 10 years where I wasn't a youth minister, but serving in other roles (mostly children's ministry), I understand I wasn't ready back then. There are days when I doubt I'm up to the task now, but I remember that with Tom, those days of doubt always turned out to be awesome learning and growing experiences.

This is the way it is when you work with high caliber folks, regardless of the field. But we have a tendency to let the reputation discourage us. That's the wrong attitude. The right attitude is to look at the opportunity for what it is. Yes, it'll be hard work. But approach it right and it should be a time of solid growth. Even taking the interview (since only one person will get each job) should be a learning experience because it shows what they are looking for which you don't know. And that tells you what to go look at in more detail if that's the field you wish to continue in. That's useful information if you want to grow your career. Also, these opportunities also represent chances to build relationships with these kinds of high caliber folks. During the time I worked with Tom, I had the opportunity to build a solid relationship with him. I still seek him out for advice quite frequently. If you get the job with a high caliber person, use the time wisely to not only learn your craft better, but also to build a good relationship with said person. Even after you both have moved on to other opportunities, the relationship should still be there.

Oh yeah, and lest I forget, working with a high caliber person can teach you to be a high caliber person yourself. A lot was made out of how, during the Olympics, Kobe Bryant showed others, like Carmelo and Lebron, how he worked and how he pushed himself. In football the same was said about Jerry Rice. In baseball it was Nolan Ryan and his bucket of rice. You see how they work. You see how they process information. You see what makes them high-caliber. And that should give you ideas of how to be likewise. I know Tom's example challenges me every time I sit down with a theology book or every time I try to think of a new idea for a ministry I'm a part of. That's what high caliber people do: they continue to challenge you to be high caliber like them. And that's yet another reason to want to work with or for them.

That's right, folks, I'm now a model. Or at least, a model DB. Tom LaRock released his most recent rankings and I've moved up from MSDB to Model. So while I won't be gracing the catwalks of Rome or Paris any time soon, I'm humbled by the props thrown my way.  

PASS has released the survey results as well as its decision about where to hold future Summit events. The decision is to keep it in Seattle for the next two years. I've been upfront about wanting it on the East Coast, so needless to say, I'm disappointed. Seattle is a hard justify for some of us on the East Coast. Case in point: I don't think a single member of my PASS chapter has been able to attend the Summit for the last three years because it has been in Seattle and their organizations aren't going for it. In my case, I was going to go last year, but it was completely out of pocket. By keeping it in Seattle, I don't see this trend changing soon. That would quite possibly be a different story if we saw the conference in Charlotte or Atlanta or Orlando or Miami, just to name a few places. Even Dallas or Nashville would likely cause this trend to change.

But based on certain numbers (and not others) the decision is to stay put. My wife has a favorite saying, "Tortured numbers will tell you anything." This, of course, originated from her statistics coursework as an undergraduate psychology major and graduate school psychology major. And when I see how the numbers were characterized, that's what I feel like the case is with the decision to keep the Summit in Seattle. Case in point, one of the justifications that was made was the results for seeing Microsoft's presence at the Summit being somewhat or very important (Q. 6). Yeah, that's to be expected. Of course I want to reach out and touch the vendor, if you give me that option. And so that's cited as a reason to leave it in Seattle. What isn't pointed out, though, is that having everything within walking distance (85%) scored higher than the Microsoft presence (the highest of the 3 was 84%). Or that free wireless (79%) beat out two of the three Microsoft-related questions as well. So this would seem to indicate that the #1 concern isn't Microsoft (that's #2), but that having a great event with proper connectivity is most important. And one can have a great event in more places than Seattle.

Then I look at Q. 7 and Q. 8. There's a net gain of 183 if we put the conference on the East coast. The gain is 229 if we held it in the central region of the US. So that means we would pick up folks who don't normally go to the Summit. Then when I look at Q. 11, the folks who want it out of Seattle every other year far and away outnumber every other category. I saw the comment about cost, and that would strike me as a valid reason, but it makes me ask, "Why is Seattle so cheap?" What makes it an ideal location over other places? And if it's such an ideal location, why does Las Vegas and New Orleans and Atlanta and Boston and Orlando get conferences? Why aren't they all going to Seattle? What are they doing that PASS isn't doing? Why are they able to get reasonable rates when PASS isn't?

Tuesday night I was having a conversation with my younger son, whom we call Turtle. It's a nickname that came from missions camp, because of his great love of turtles. For my oldest son, we told him that when he hit age 12, he would need to pick a musical instrument and this would become part of his homeschool curriculum. He chose the guitar, and so now we refer to him as Guitar Boy in public posts. My oldest has worked hard, taking weekly lessons and practicing nearly ever day. And when I say practice, I mean he is investing a lot of time and effort into it. He wants to master classical guitar. Part of the reason is we didn't dictate what instrument he would learn. We told him to pick the instrument he wanted to play. We've done the same thing with Turtle. His choice is coming up as he is 16 months younger than his brother.

Now Turtle does a lot of things off the beaten track. That's the way he is wired. So we went through a lot of instruments on-line, watching performers on those instruments, so he would get some ideas as to what he might want to learn when it is his time to choose. Among those we looked at were the double bass, pedal steel guitars, dulcimers of various types, Chinese and Japanese bamboo flutes, the koto, and, of course, bagpipes. The picture here is of The Citadel pipe band, who will be returning to the Edinburgh Military Tattoo this summer to perform (as part of the combined Citadel Regimental Band and Pipes). Unfortunately, I arrived at The Citadel one year too late to go the first time, but being a member of the Regimental Band and Pipes has left me with a love of bagpipes. However, Turtle has pretty much ruled them out. While I would love for one of the boys to learn them, if it's not their passion, I am not going to ask them to do so.

My wife and I had a long conversation about what instruments for the boys to learn a while back. We're both flutists. We both played french horn in high school as well. I learned trumpet, too. But our primary instrument is flute. If it were what would be easier for us, the boys would both be learning flute. Failing that, they would be on french horn. But I know what it's like to try and play an instrument that's not your passion. When I first started on flute, I hated it. For me, what changed my attitude was a book of sheet music with Japanese folks songs. Playing through the songs and being able to recreate the same songs that I heard around me constantly (we were living in Iwakuni, Japan at the time) changed my heart towards flute. I saw a lot of other friends who never grew to have a passion for the instrument they were assigned. They no longer play. As a matter of fact, most dropped out at the end of junior high school. So we came to the decision that the boys would pick their instruments, we would find them instructors, and we would encourage them and help them with the music theory aspect of learning how to play their horn (or guitar, as is the case with Guitar Boy). Turtle is undecided. He's leaning towards guitar, like his brother, but the decision will be his and his alone.

When it comes to what we do, we need to find where our passion is. I love SQL Server. That's why I chose to step back from an infrastructure architect role to become a DBA again. Active Directory, Citrix, and virtualization is great. Worrying about enterprise security? Not so much. I like to sleep at night. Tinkering with hardware is fun, until you have a whole batch of servers have the exact same motherboard issue and you've got development teams and end users all screaming about the fact that their servers are down and you're waiting on the vendor to bring parts on site. Bad queries? Fixing data models? Yeah, those are headaches. And they can be just as big of a headache as the other cases. But because I love SQL Server, that's just part of the fun. I know, it may seem crazy to describe troubleshooting poorly performing queries as fun, but that's what passion does. It turns what is drudgery and pain for another into something that is, well, fun, for the one who has a passion for that field.

When it comes to IT, there are so many things to do, so many technologies to work with. The thing is to find what you're passionate about. If you don't have the skill set for it, build yourself up. Take baby steps if you need to do so. Look for opportunities in that area. It's better to work in your passion, where it doesn't seem like work, then slave away at some area which you hate. Even if that other area pays a lot better, it's just not worth it in the end.

I had a really bad habit of trying to jump into the middle of something I didn't know very well, if at all, especially when it came to technology. I attribute it to my days of playing video games when you pulled the game out of the case, stuck it in, and then tried to figure out how everything worked. Yeah, there was an instruction manual, but who had time for it? This was reinforced by arcade games, especially the fighting games like Street Fighter II Champion Edition where there were no instructions other than then basics on how to punch, kick, jump, and block. But every character had special moves which made them more lethal. So before the days of widespread Internet access, we learned by trial and error. 

As I've gotten older, I've realized that this isn't such a great idea. Maybe it was working with high molar acids in chemistry lab, or maybe it was realizing how much time I wasted by fumbling around. In any case, I've learned that taking a more methodical approach is often the right way to go. Sure, I still jump into something with enthusiasm, but I do so knowing that I'm starting at the beginning of something, not the middle, and that I can formulate a plan to advance. In many cases I'm taking baby steps, like the baby flamingo to my right (my little girl loves flamingos, so you all get flamingos).

For instance, I want to learn how to play the penny whistle, like Sir James Galway does here. There is a process to learning a new musical instrument, even if you are already very familiar with another, like I am on flute. Playing a penny whistle is similar to playing the flute, but the embouchure is different. Also, the fingerings are not the same. So there's definitely a learning process. The first step is to learn the first few notes. Then one plays long tones of those notes. After that, one attacks a simple melody using those notes. And slowly but surely one increases the range of notes as well as the complexity of the music that is being played. It matters little that I have full range on the flute with the practiced capability of playing sixteenth and thirty-second notes. Sure, I can read the music readily for the penny whistle, but my fingers still have to practice to get used to where they need to be and how they need to flow to play the penny whistle properly. I must learn how to put the proper amount of air and form the proper embouchure to ensure each note is on pitch, not flat and certainly not sharp. And that takes time. That takes baby steps. I'm not going to sound like Galway overnight, nor am I going to play with the dexterity of this guy any time soon. Those are goals to reach for. I expect a lot of personal failure along the way.

But it all starts with baby steps. Anything worthwhile does. If there's something you want to learn or something you want to tackle, look at it objectively. Figure out what you can truly handle. Perhaps that means you'll have to take really small, even baby, steps. That's okay. The key is to steadily move forward. Make sure you've got down what it is you're learning before moving on. This is true whether you're learning how to swing a bat, play an instrument, learn query tuning, or become a great chef. Expect to fail, but don't let failure discourage you and certainly don't let it stop you. Rather, take the time to learn why you failed, what you didn't fail on, and how to avoid or overcome the failure on the next attempt. Maybe you took too big of a step. Or perhaps you just need to repeat whatever that step was until it becomes second nature. But keep taking steps forward.

I'm reading a book by two teens called Do Hard Things. It's a book which represents a rejection of the low values and expectations the world at large has for teenagers. Their point is that just because you're aged 12-18, the belief you are incapable of taking on difficult challenges is nonsense. See, the idea of the "teenager" is actually a relatively new one, and the result of excesses of the Industrial Revolution. Before that, there were two categories: children and adults. They cite examples like George Washington, Clara Barton (who would later found the Red Cross), and David Farragut (who had his first ship command at age 12) as examples of teens or younger who did great things at that age. If you want to read more about what they're saying in that arena, check out the book or the web site. I'd like to focus on a point they make, which I've seen pointed out before by other performance coaches. That's the idea that personal failure is simply a result.

Inevitably, when we try to do things, sometimes we're going to fail. That's life. For instance, consider that if you fail to get a hit in baseball 65% of the time, you'd be considered one awesome hitter. Now simplifying things and taking out walks, sacrifices, and the like, that still means you fail almost twice as much as you succeed at this simple task. Only a rare few can maintain this kind of clip in Major League Baseball. And they would be considered success stories. So why are we so afraid of a personal failure? Some would say because there is more riding on our successes and failures. But that's not necessarily the case. For instance, a single swing of the bat can mean a sizable difference in the fortunes of certain individuals and teams. Just ask the Red Sox about this historic homerun. That little ball flying out of the park resulted in a change of fortune for two baseball teams. So why do we put so much emphasis on personal failures?

Often we treat failure like a disaster. We treat failure like an incurable disease. As a result, we become afraid to try something new. We hesitate to attempt something great. We may be miserable where we are, but at least we understand and know where we are. Failure brings about an unknown. For that matter, so does success. So we simply don't try. We don't push ourselves, or at least we don't do so with any sort of intensity and passion. And then, years later we wonder why we haven't gone a lot further than where we find ourselves.

Instead of treating personal failure like a disaster, we need to treat it simply as a result, like 5 or 7, or blue. In the effort of trying, we should gain or improve or grow. For instance, the first time I stepped up to the plate, I made about 11 or 12 bad swings out of 15. The good swings were not due to any skill. I simply didn't know how to swing the bat. But I got up there and tried. That's what you did in Little League. My dad promptly took me to a batting cage a few times and within a couple of weeks I had a really decent swing. I learned from my mistakes. I learned how to choke up to get better control of the bat. I learned how to step properly to shift my hips and put power into my swing. I learned how to make the swing itself relatively short and compact, so that I could rip it through the strike zone quickly. As a result, there wasn't a pitcher in our league I couldn't the ball in play against and I ended up hitting lead-off because I could either take the walk (I developed my eye, too) or slap hit a single and then proceed to steal second and third, meaning I came home for a run most times I got up to bat. But that only came after many, many failures to simply make contact with the ball, much less make good contact. Over the next three years I worked on my swing a lot. At the end of my short baseball career, I left with my swing being the best part of my game. Far better than my fielding and throwing and my speed, which started out as my greatest strengths. Over the course of that time I learned how to lengthen my swing and my step to generate even more power. I was slid from lead-off to clean-up and went from the guy who set up the rest of the hitters in the line-up to the one who hit them home. But all of that came with a lot of failures. Learning to hit someone who threw sidearm. Learning to lay off the high heat. Learning to read a breaking ball coming in. Learning how to soften up on a bunt. That last one was one of the hardest things to learn. I can't tell you how many times I pushed the ball and failed to get the bunt down before I felt comfortable laying a bunt down in a real game. Each time was a failure. But it wasn't a disaster.

And so it needs to be this way in our own goals and achievements. Failure is a result. What did we learn from the process? What skills did we develop? Did we grow? Can we do better next time? This is how our minds should be focused when it comes to personal failure. If we do it this way, we position ourselves for a better result the next challenge we take on. And we're not afraid to take on that challenge. After all, we know that whatever the result, we'll grow from it. And that changes our attitude about the challenge. Now we want to tackle it to get better. It may be hard and the result may be failure, but that's just a result. What we gain will be worth it. We just have to convince ourselves that failure is a result and not a disaster.

Notice I didn't title this "Plan to Fail." We should never plan to fail. That's sabotage. And that ain't right, as we say in the South.

However, when we do our planning, it is an unrealistic expectation for everything to work every time, especially when it comes to IT. Our systems are getting more and more complex with each passing year and there are more and more points where a failure can occur. So it is realistic to plan for failure. After all, that's what recovery, and especially disaster recovery, is all about. Take, for example, the bridge in the picture (Photo: NOAA). This is the Ben Sawyer Bridge and this is what it looked like after Hurricane Hugo got a hold of it. Needless to say, in this state, it wasn't usable for car traffic. This blocked off the only accessible means to Sullivan's Island for normal land transportation.

When we architect systems and processes, we don't want to be in the same sort of situation. We want to make sure that if there is a failure, our systems will handle such gracefully. The only way they can is if we plan for failures to occur. And as we plan, we should consider the advice of those who have gone before us. For instance, the 8 Fallacies of Distributed Computing.

Fallacy #1 is an important one: the network is reliable. What that's basically saying is it is a fallacy to assume that every time you plan on using the network, it is up. I have seen cases where someone was working on a server in a rack and the network cabling for a different server is affected. Sometimes this isn't obvious at all. For instance, the cable looks like it's still plugged in to the back of the server, but things are just loose enough where good contact isn't being made. So now we have a physical fault and the network, at least as far as that one server is concerned, is not available. Or it could be the case like a few years ago where there were some issues with some of the Broadcom NIC drivers and we were affected. In our case, the loss of network connectivity couldn't be predicted. Everything worked okay and then, *blip* the NIC was off-line. What made matters worse was as far as the OS was concerned, everything looked fine. Now the fix was a simple one: log on locally and disable and re-enable the NIC or simply reboot the box. However, that did mean someone had to log on locally. Unfortunately, that KVM wasn't network enabled at the time.

So planning for failure is a proper part of the architecture design. Another would be to look to minimize the chances of failure. For instance, looking at fallacy #1, if I can get to a point to where a network failure doesn't affect me or I can minimize the damage done, all the better. This may simply be a case of copying the flat file extract from the mainframe to the system holding SQL Server where the SSIS package is going to run. Sure, a network failure during the copy could prevent me from starting the data import, but that's a lot better than a network failure occuring during the data import because I'm importing said file across the network. The first case is easy to deal with. I restore the network connectivity, get the file copied over, and start the ETL process. In the second case, I've got to restore the network connectivity, but I also quite likely have to do some data clean-up, depending on how far along I was when the failure occurred.

So plan for failure. And look to minimize the impact of failure. Two general steps to include in architecture design.

Back a couple of weeks ago I had the privilege of participating in a Pain of the Week webcast with Kevin E. Kline on SQL injection. The webinar archive is now online if you didn't get a chance to view it live:

Quest Pain of the Week Webcast - SQL Injection - February 11, 2010

One of the things I talked about was how attackers will use search engines to try and locate targets. This is typically known as Google Hacking and the guy who I most know for this is Johnny Long. He has a Google Hacking Database online.

I'm a big believer in looking at systems when everything is okay. I'm not the only one, as Joe Richards, a Directory Services MVP, commented the same thing a while back. If you work with Active Directory and you don't know who Joe Richards is, you need to go ahead and revoke your domain and/or enterprise admin rights. Go ahead, I'll wait.

Back when I was a systems and security architect, I spent a lot of time looking at processes and looking at packet traces. I wanted to know what was usually running on a system and what kind of traffic it generated. Getting an idea of what is normal meant I was better able to spot what wasn't when a problem came up. For instance, if our server is having an issue and I'm seeing some process called abcprocess.exe running in Process Explorer that I don't ever remember running, that gives me a starting point. Lo and behold, after some investigation I find abcprocess.exe is homegrown, and it went in as part of a build day before yesterday. And the problems started... day before yesterday. When we stop abcprocess.exe from running and the problems go away, it looks like we've done some magical troubleshooting, kind of like pulling a rabbit out of the hat. Well we did, but we knew that the hat had a false bottom, so pulling the rabbit out was easy. After all, we knew abcprocess.exe didn't normally run on that server. And that's what started our wonderful magic trick.

This is something that should be applied to all systems. I was reminded of it recently when trying to write reports for a 3rd party application. It's a small company with a very specialized application and database. You can translate specialized as customized. With respect to a particular report, try as I might, I couldn't find a particular code that was supposed to be in a column in the database. I looked in all the logical places based on table names and found zilch. I was at a loss. The problem I had run into was I wasn't familiar with this database. I hadn't run traces to know what kind of queries hit the database and what tables and columns they were querying. So I didn't know how everything looked when it was okay. Eventually, after a lot of searching, I finally found the column. It's in a table that logically doesn't make sense based on naming. But it's the right column. I know this because I built a quick reconciliation report query, and let the end users verify. And so I was able to produce the report.

But what struck me as I was completing the report is I still don't know what the queries look like when everything is fine. I need to take time to do that. I need to set up traces and the like, just to get an understanding of how this application operates against this particular database. This is now especially true since I've determined that in some cases the customization that has performed is not logical. It's only a matter of time that they have a real issue. And if I haven't spent the time understanding how this system performs when everything is okay, then my troubleshooting is going to be longer and more difficult than it should be. It'll be like trying to catch the rabbit to stash him in the hat. I'd rather him already be in the hat.

I was having a conversation recently with a friend and former co-worker of mine. He's bounced around here and there, looking for better positions. And when he first began that journey, it looked like he was heading in the right direction. But with the down turn in the economy, his choices have become more and more limited and he's had to accept less than what he has wanted. He has also faced the fact that he's been cut loose when the company wasn't doing as well as it wanted. That's the way it is with this industry or any other industry. But that's not the point of this post.

My friend had recently been laid off from a full-time position at one job. His old job extended his benefits and pay as part of a severance package, which admittedly they didn't have to do. In South Carolina they can just say, "Your services are no longer needed," and that's that. Now my friend took advantage of a loophole in the benefits coverage and maximized that loophole. What he did was completely within his employment conditions as well as the law for this state. Nothing is at issue there. My friend didn't do anything illegal. Let's clear that up right away. But whether or not it was ethical is a good question.

The former employer was upset at my friend for using the loophole when they extended benefits and pay for my friend's benefit. And because of the fact that my friend used that loophole, it will come out of the employer's pocket. It's not a lot of money, but when you're a small business (as this employer is), every little bit hurts. The employer has a new part time opportunity that might have gone to my friend. However, after what he did, my friend doubts that he will get that part time opportunity. Knowing the employer personally, I doubt that my friend will get the job, unless the employer can find no one else. In the employer's eyes, I'm sure my friend has burned his bridges.

A good rule of thumb I try to follow in life is, "How I would react if the situation were reversed?" We call this the golden rule (and not the one from Aladdin), and in Christian Scripture it's the second greatest commandment ("Love your neighbor as yourself"). When I posed the situation to my friend, for him to imagine he was the employer, he did understand why the employer was upset. He would be, too. And this raises the question, "Then why did you do it?" I never asked my friend that question, because I wasn't sure I would like the answer. I would surely get a lot of justifications, and there are extenuating circumstances in play, but justification is another word for excuse. At the end of the day, what my friend did would be considered a violation of trust. I know that's how his former employer would see it. That's how I see it. And both his former employer and I think alike on this one: if you violate my trust I wil forgive you and move on, but I will be very careful not to put myself in a similar position unless you can, over an extended period of time, prove somehow that I can trust you again. How exactly one proves that he or she is trustworthy again is not a question I can answer. And that's the situation my friend finds himself in with his former employer.

And this comes down to the question of what is legal versus what is ethical. Several of my co-workers and I discuss this distinction at least a couple of times a week. What is legal is pretty clear cut. What is ethical isn't so easy to determine. Everyone looks at situations differently. For one of my co-workers, squeezing in within the boundaries of the law is enough. For me, it goes back to the rule of thumb question. If I know it's not how I would like to be treated or if the situation was reversed I would be angry or offended, then likely it's not ethical. If it's not ethical in our minds, even if it is legal, we ought not be doing it. That's where I think my friend made a mistake. If he applied my rule of thumb, he would have felt the former employee would have been treating him unfairly and violating his trust. So to turn around and do it himself would certainly fit that unethical side of things. But because he didn't sto himself, he has burned a valuable bridge. I'm just hoping that doesn't come back to haunt him in the future. I know in some ways it will. I was the one who recommended my friend to his former employer. After seeing what my friend has done, I am very hesitant to do that again. It's something I'll have to think long and hard about. How do you give a recommendation properly without giving some type of warning? That's something else I don't have a good answer to.

After seeing Brent Ozar's Top 10 Reasons Why Access Doesn't Rock, and seeing all the comments it generated, I figured I would throw my two cents in. Now it's important to understand that I'm speaking here of the database portion itself, which I have seen used more frequently than it should have, for supposedly enterprise class solutions. And with regards to this blog post, I'm going to speak from my former role as an infrastructure and security architect, not from the perspective of a SQL Server DBA. I realize that for small organizations, Microsoft Access may be a viable solution. It, like every tool, has its place. But within the enterprise, I think there are better solutions. Here are some of the issues I've encountered having to support Microsoft Access.

The Locked Database

Access is a file. While there is a mechanism to allow multiple users to connect in, it doesn't always work so well. I can't tell you how many times either I or someone in a system administrator role had to bring up computer management, connect to the file server, and sever someone's connection manually because they had somehow managed to lock the Microsoft Access database that other users were trying to use. On a busy file server, this is a chore. It takes time to find the right connection before you kill it. Meanwhile, end users are screaming because they don't understand why the database is locked.

Now I realize that SQL Server can get locked up to the same effect on the end user. That's one reason there's now a Dedicated Administrator Connection. But in my experience, that has been a very rare occurrence. I will say the same about Oracle. They are designed from the ground up as multiple concurrent user systems and they tend to work rather well at that. Microsoft Access doesn't always do so.

The Locked Out Database

This is similar to the locked database, but not quite. In this case, one user who has the permissions to do so (Full Control) decides to try and tighen down security on said Access database. Since the database is a file, he or she tries to really tighten it down, and tightens things down too much. Other users suddenly can't get in and they don't have any idea why. System administrators who investigate the problem can initially get in, and then it hits 'em: someone has messed with the permissions. So then it's a matter of trying to figure what the right permissions are supposed to be. And that can take forever, causing certain end users to be unproductive and tying up the time of a system administrator who could have avoided all of this had the solution been in a SQL Server back-end.

The Misplaced Database

If a user has the ability to write to the file, the user has the ability to move the file unless you decide to get pretty granular on your file permissions. Most folks don't. And it wasn't unusual to get a help desk ticket where an end user claimed the Microsoft Access database had been deleted. It wasn't. It was moved to a folder by accident. And unless you go poking around in all the child folders, you don't know this. This sort of thing doesn't happen with SQL Server. It can't. An end user can't drag and drop SQL Server into oblivion.

The Deleted Database

Just as the end user has the ability to misplace the database, the end user has the ability to delete the database. This is always bad news. If you've got a system where deleted files are held, even if the user can't see them, then it's not so bad. But then you've got to engage a system administrator from another task to recover said database. Even in cases where said system allows a user to recover the file for himself/herself, it still seems like most of the time we're still doing the recovery. With SQL Server an end user may be able to mess with the data, but even this can be controlled. They should certainly never be in a situation where they can blow away the whole database.

The Database Backup Not Taken

A Microsoft Access database is a file on a file system. As a result, it gets backed up when the rest of the file system gets backed up. This is usually once a day. So if the user mistakenly does something to lose or corrupt data, then there's an issue. You have to restore from the previous backup. And that may have been the one that ran at 3 AM. And that means unless the user thought to do so and manually made a copy, any work to that point will be lost. With SQL Server, backups can be taken more frequently, automatically, and without interrupting the user's work. In addition, with point-in-time recovery you can get back to right before the mistake was made.

The Insecure Database

Microsoft Access wasn't intended for the granular security that we find in RDBMS products like SQL Server or Oracle. And invariably when that IT auditor hear's data is being stored in an Microsoft Access database, they start asking all sorts of questions. That auditor is only doing his or her job. Basically it comes down to the case where a compensating control is required to add security to the Microsoft Access database. Usually these are additional procedures and we know that these don't work out so well. Sooner or later someone is going to be in a rush or someone is just flat out going to forget and the procedure won't be followed. And then you have a security issue. With SQL Server's granular security, we don't have this issue. We can generate who has rights and exactly what rights and if there's a problem in the IT auditor's eyes, we can adjust the security as necessary.

In Conclusion...

There's more, certainly, but those are enough to explain why avoidance of Microsoft Access as part of a solution for an enterprise. If you are support a mom-and-pop shop or a small business, it may be the right tool for you. But in the enterprise where more robust solutions are available, I say stay away from Microsoft Access. It may be easier on a particular developer, but you'll pay back any savings on the developer's part with the maintenance nightmare you create for the operations staff. And it won't be very long until the numbers flip and it actually costs you more in maintenance than you saved using Microsoft Access in the first place.

 Today I'll be tagging along with Kevin Kline for the Quest Pain of the Week webcast. We'll be talking about SQL injection. The title is:

Understanding and Preventing SQL Injection Attacks

The webcast will be at 11 AM Eastern Time / 8 AM Pacific. If you register, you'll also have a chance to win a prize.

ATTRIB is one of those commands back from the days of DOS which most folks don't even realize it's there. The purpose of the command, as its name implies, is to manage the attributes of files and folders. There are 4 attributes which it can manage:

• A - Whether or not the archive attribute is set (this can tell a backup process if the file has changed since the last backup).
• H - Whether or not the file/folder is hidden.
• R - Whether or not the file/folder is read-only.
• S - Whether or not the file/folder is treated as a system object.

We don't use it too much any more because the Windows GUI tends to allow us to manage the A, H, and R attributes just fine. One of the few cases where you would have to resort to ATTRIB is if the file is marked as a system folder. When cleaning up some malware from another person's desktop yesterday, I ran into this. In that particular case you can't make the file visible again, nor can you change it from being a system file without the use of ATTRIB. The following image shows that the hidden checkbox is grayed out when both of these attributes are set:

This is how the HOSTS file was set because the malware automatically inserted its own entries for common sites like www.google.com. For the average user, these settings means that even if they knew exactly where to navigate to, they wouldn't have been able to fix the file. Enter in ATTRIB. ATTRIB with just the name of the file or folder can tell us what attributes are set. Here's an example against a protected HOSTS file:

C:\WINDOWS\system32\drivers\etc>attrib hosts
A  SH      C:\WINDOWS\system32\drivers\etc\hosts

Note that A, S, and H are set. Now one of the things about it being a hidden and system file is if I try to undo just the system attribute or just the hidden attribute, it won't work. Here's what you'd see:

C:\WINDOWS\system32\drivers\etc>attrib -h hosts
Not resetting system file - C:\WINDOWS\system32\drivers\etc\hosts

C:\WINDOWS\system32\drivers\etc>attrib -s hosts
Not resetting hidden file - C:\WINDOWS\system32\drivers\etc\hosts

As you can probably guess, the - (minus sign) tells ATTRIB to try and remove the attribute. If you wanted to add an attribute, like I did for this example, you would use + (plus sign) instead. However, back to how to solve this quandry, the trick is to toggle both attributes off at the same time:

C:\WINDOWS\system32\drivers\etc>attrib -h -s hosts

C:\WINDOWS\system32\drivers\etc>attrib hosts
A          C:\WINDOWS\system32\drivers\etc\hosts

And with the hosts file in this state, it was back to the way it should have been configured, with the exception of the entries inside of it I still had to clean up because of that malware. As a matter of fact, I had to use ATTRIB one more time on a folder in order to allow for a folder where the malware was hiding to be discovered by the security scanners.

This is one of those cases where an old round of DOS knowledge allowed me to do something you couldn't do through the Windows GUI. Knowing little tricks like these can often make a difference when you're troubleshoot or correcting issues like the one I was facing. Without knowing ATTRIB and how it worked, I don't know that we would have been able to clean the computer. The malware were rogue antivirus software packages and they were preventing other AV packages from installing and running properly. These rogue antivirus programs are on the rise because they prey on an innocent person's trust. The person will trust the information that just popped up is legitimate, and the rogue product gets installed. The end user doesn't know better and the software itself tends to be difficult to clean up.

This past weekend I was at the Columbia Code Camp, which was a rousing success with 6 tracks, a number of great speakers, and 165 attendees. This despite freezing rain and losing some speakers from North Carolina due to the weather. I was a volunteer and speaker (last minute on this one, to fill a slot for a speaker we lost due to the inclement weather), and I wanted to write a little about why volunteering for a Code Camp or SQL Saturday may be a rewarding experience. I've come up with four things I think one gains by volunteering. They are:

Free Training

The purpose of a code camp or SQL Saturday is to provide free training to IT professionals. They do tend to occur during the weekend. And if you're not a volunteer, it's easy to find a reason not to go. But when you're a volunteer, you know folks are counting on you, so you feel an additional responsibility to show. And once you get on-site, you get to attend the sessions during the time you're not volunteering. For instance, this past Carolina Code Camp I was able to hear great sessions from folks like Andy Kelly, and Jim Wooley. If I hadn't had to present, I would have been able to hear Alejandro Mesa's session, but alas it was at the same time as mine. I was proctoring the second of the two SQL tracks, or I would have made sure to hear John Welch, whose sessions were all in the first track. And all of this is provided FREE! You can't beat that.

Meeting People

Code Camps and SQL Saturdays are a great way to meet new people, people with like technical interests. Because of SQL Saturdays I've met folks like Jack Corbett, Rachel Hawley, Chris Rock (the .NET guy, not the comedian), Kevin Kline (the SQL guy, not the actor), Stuart Ainsworth, and Robert Cain. I've met folks like Alejandro at code camps. I've been able to build upon pre-existing relationships with guys like Andy Warren, Steve Jones, Brian Knight, John Welch, and Andy Kelly. They are real people, not just SQL and .NET gods, and you get to interact with them in the flesh. This is worth the time, in and of itself.

Learning How to Run Your Own

The Columbia Code Camp was run by Bobby Dimmick and C# MVP Chris Eargle. Chris has been to a lot of Code Camps and he had learned a lot about how one should run. Bobby is a naturally smart guy with a flare for organization and administration. Together they made a great team. One example of where previous experience came into play is the giving out of SWAG at the end. Chris found a neat application that automated the raffle drawings. It was originally in Ruby but he got permission and converted it to .NET. That thing probably saved an hour. Previous experience had shown him the need for one. By going to the other code camps, Chris was in a good position to help get one going in Columbia, which was nice. It's nice to do these local.

I need to say that if you've never run your own and you're not surrounded by folks who have run or been a part of conferences before, it can be a daunting task. When I first reported to the USAF, I was thrown into the middle of what was then called the Air Force Small Computer Conference as the special assistant to the conference chairman. A week long conference that averaged 3,500 attendees. There was a lot to do, from running down notepads (with a really nice organizer with it) that had to be put out to bid, to replacing a keynote speaker when HP's CEO pulled out, to handling the mess that was initial on-site registration once the conference began. But it prepared me well. The next year, I was co-chair of it and we renamed it the Air Force Information Technology Conference (AFITC). That year we had 5,000 attendees, video teleconferencing of keynotes, including a VTC session in to the conference attendees from then Secretary of the Air Force, Dr. Sheila Widnall, from her desk in Washington, D.C. I also participated in the next three on the technical side of things. Each time I volunteered, I was better equipped for the next one. And having done a big conference like AFITC, helping out with the Columbia Code Camp wasn't very stressful at all.

Learning Something More About Yourself

Every time I volunteer, I learn something more about myself. This particular time around I was less hands on and served more to assist Bobby Dimmick with questions and advice. Most of the time I was just a sounding board as he worked through issues that always come up in the planning for these types of things. That was a new role for me. I learned a lot more about listening to others and about the importance of letting folks work through some things on their own. I've always been in the midst of things, especially with the AFITC. Hands-on, immersed, with a ton to do and not a lot of time to do it. We always were scrambling. Planning for an AFITC began even before the current one concluded. We would start a week out setting up the site. And it seemed like there were always things to have to do the Sunday before with early check-in or Monday when the conference spun up. It was a great chance to watch a smart guy work through what needed to be done, come up with his own solutions, bounce them around a bit, and then see him execute. I know Bobby learned a ton and we're already talking about whether or not we can finally bring a SQL Saturday to Columbia, or perhaps even to Myrtle Beach, as Andy Kelly posed. We'll see.

So if you've not considered volunteering, please do. It's a great experience. You'll learn a lot, and not just in the sessions. You'll meet great people. And most of all, though I didn't list it as one of the big four, if things are done right (and even if they aren't), you should have a lot of fun. It takes a lot of energy, but at the end of the day, you get a huge sense of accomplishment as the event rockets through to completion. Find one near you, volunteer your time, and make yourself available, even if it's a stretch for you to do so. It is likely an experience you will enjoy and grow from.

We're making a final push to let everyone know about the Columbia Code Camp 2010, which happens tomorrow, January 30. It's being held in downtown Columbia, and there are 6 different tracks, including 2 SQL tracks (yes, 2 SQL tracks at a code camp). From the SQL Server side speakers include myself and SQL Server MVPs Alejandro Mesa and Andy Kelly. If you're anywhere near the area and want free training on .NET, mobile (including two BlackBerry sessions), and/or SQL Server, come on over and see us. More information can be found on the web site:

http://columbiacodecamp.com/