Free Newsletters

   All InfoWorld Newsletters
Google Search » Database Underground | Sean McCown » January 2007

January 26, 2007 | Comments: (0)

Don't Get Left Behind

I always like to pass along things like this when I get the chance. My PR rep from AppDev just sent me their roadmap for the first part of this year, and so far it's looking pretty good.
Most of you know how big I am on training. I don't think DBAs should rest on their DB knowledge alone. These days there's so much more to it than that. You have to know so much more that you used to.

Anyway, here are some of the courses they're putting out, and I for one can't wait. I'll be reviewing them as they release, so I'll keep you guys updated on the progress of that.

I'm serious guys... AppDev is some of the best training out there, so if you want to get started with any of these technologies, this is an excellent place to start. If none of you have ever seen any of my reviews on their material before, you can go here.

**Building Web Services Using Visual Basic 2005, ships 2/28/07
**SQL Server 2005 Analysis Services, ships 3/15/07
**SQL Server 2005 Integration Services, ships spring 2007
**Advanced .NET Framework Using Visual Basic 2005, ships spring 2007
**Advanced .NET Framework Using Visual C# 2005, ships spring 2007

If you click on the links, I've got the TOCs on PDF so you can see what they'll cover. I don't have the TOC for SSIS yet, but I hope it's coming soon and when it does, I'll post it.

Posted by Sean McCown on January 26, 2007 03:10 PM


January 25, 2007 | Comments: (0)

RTFM

I just got my copy of Powershell TFM by SapienPress.  I was lucky enough to get an advance copy last year at TechED, but it only had the first 4 chapters.  Anyway, the book is beautiful, and very complete.  I've only spot-checked the final copy, but I already know that reviewing it will almost be perfunctory.  Don Jones wrote this, and not only have I never seen him put out crap, I've thoroughly enjoyed everything I've seen from him.  I reviewed his VBScript videos a while back, and you can see it here

There are a couple things I like about this book.  First of all, I'll read anything with such an enjoyable title:  Powershell TFM.  Can you get a better title than that?  Of course, on the cover they have a definition of TFM, which they translate as 'The Foremost Manual'.  That's the only thing that gets me.  If you're going to have such a great title, go all the way.  Don't hide behind your mother's skirt and peek out from behind.  We all know that it really stands for 'The F'ing Manual'.  They even make mention of the old saying RTFM (without translation I might add) right on the front cover.  So I say, if you're going to have a TFM, have a proper one... go all the way with it and say what it really is.  And for those of you who don't know, RTFM is 'Read The F'ing Manual'.  It's what you tell someone when they ask you a really basic question about something.

The other thing I like about it is Don Jones.  Like I said, I've enjoyed his stuff for quite some time and he really has a way of explaining things in not only an easy-to-understand, and complete way, he also tends to go in the right order.  I've reviewed many books and videos, and sometimes the order people choose to teach things in is really confusing.  Jeffery Hicks co-wrote this with Don, and I'm sorry to say I'm not familiar with his work at all... sorry Jeff.

Now, why am I mentioning this in a DBA blog?  Well, because Powershell is going to be important to us all.  I don't see it going away, it's simply too powerful of a tool to let go.  I do believe it'll take some time to catch on, but as soon as Exchange 2007 starts taking hold, and Vista, and Longhorn are in tight too, you'll start to see people enjoying the flexibility of Powershell.  I actually believe that Powershell could replace SMO for SQL management.  There's no reason it wouldn't.  MS has already said that Exchange 2007 was written to be fully compatible with Powershell, so it's only a small leap to making that same requirement of SQL Server.  I'll ask them what their plans are for SQL and Powershell when I have my next talk with them in a couple weeks.

I also think that DBAs should start learning Powershell now.  It's an incredibly powerful scripting environment for Windows, and something we've needed for a long long time.  I personally get called into writing VBScript in Windows fairly often, so I can't imagine that everyone else is escaping that task.  Like I've said on a number of occasions... DBAs often get called on to do all kinds of things that are officially not part of our jobs, simply because we know how.  We've always had to script DTS in VBScript, so it's only natural that they ask us to do the Windows VBScripts if it needs doing.  So what kinds of things have I had to script?  Well, I've had to script performance collections a lot.  If your dept doesn't have a lot of budget for expensive monitoring tools, then you do what you can.  So I end up writing different WMI scripts and performance counter stuff and log it all to a DB so I can either alert or report off of it.  This is exactly the kind of stuff I'll be looking to Powershell to take care of for me because it's so much richer than VBScript.  I've also had to script service stop/start scenarios to help clear user connections before major DB operations.  I've also written a load balancing script for a TS farm.  And let's not forget the WMI/VBScript for matching LUNs up with drive assignments.  Anyway though, the point is that DBAs have plenty of occasions to flex their scripting muscles outside of SQL, so learning Powershell is the next logical step. 

But why should you learn it now?  Why not wait until it's a little more ubiquitous?  Well, again, you don't want to be a complete beginner when the market shifts in that direction do you?  You want to have a few months at least under your belt, and if possible, a year or so.  It's amazing... though you think you won't need it now, that's only because you don't have it in your toolbox.  Once you see the types of things you can do, you'll go out of your way to script projects in Powershell. 

Now, for the setup.  Do you have to actually have Vista or Longhorn to run Powershell?  Actually, Powershell didn't make it into Vista, so you have to download it separately.  There's also a version for XP, so you can start using it right away.  Here's where you can find out more and even download Powershell.  If you're not sure why you should even learn it, then get this book because Don and Jeff tell you exactly what it's all about and why.  And trust me... when another year has gone by and you still haven't done anything about Powershell, you'll hear my words in your sleep.

So seriously... RTFM guys.

Posted by Sean McCown on January 25, 2007 06:55 PM


January 11, 2007 | Comments: (0)

The Preposition Connection

I just realized that yesterday I promised to talk about how prepositions get thrown into the mix. It's pretty easy really.

Let's start out today's discussion with the difference between who and whom.

Again, who is subjective, and whom is objective. So to recap from yesterday, subjective means that it acts as the subject and objective means that it acts as the object. Now, the object of what... well, the object of a preposition (in this context anyway).

Take the following examples:

Did you give the SQL code to Mary?
Did you give the SQL code to me?
Who did you give the SQL code to?

OK, these sentences demonstrate a few things.
1. Both Mary and me are objective. They're the object of the preposition to.
2. Even though it's widely used, you cannot end a sentence with a preposition.
3. Who is used incorrectly here.

First of all, a preposition is a word that starts a phrase that modifies a verb in such a way that it notates some kind of spatial, temporal, or other kind of relationship between the noun in the phrase and the verb being modified.

OK now... I know that's kind of a thick definiteion. It's really just a fancy way of saying where the action is putting the subject.

Let's look at a simple example:
The cow jumped over the moon.

Here, cow is the subject. He's the one doing the jumping.
The cow is jumping... that's the action the cow is performing.
What object is the cow performing this jumping action on? The moon, that's right.
Now, is the cow jumping to the moon, over the moon, through the moon, by the moon, at the moon, etc?
Get it? The preposition 'over' modifies (or changes) where the cow is jumping. It doesn't change the cow in the least. The cow is still a cow and isn't being described at all. But the jump IS being described... it's 'over the moon'.

That's why you officially can't end a sentence with a preposition. It's in the name... preposition. It's pre-positioned (positioned before) its object. Therefore, if the sentence ends in a preposition, then isn't an object after it, and therefore, it's not a good sentence.
So back to the sentence: Who did you give the SQL code to?
If you re-wrote it just as it stands, you would write it like this:
You gave the SQL code to who?

Again though, that's not entirely right. See, again, the word 'who' is subjective, and 'who' clearly isn't the subject here. It's the object of that preposition that comes before it. So you have to use the objective form 'whom'.

So the correct sentence can have 2 forms:
You gave the SQL code to whom?
and
To whom did you give the SQL code?

It's just that easy.

I know this sounds like a lot, but it's really not. Just remember when the subject is 'who', you can use 'who', otherwise use 'whom'.

So how many of these sentences are right?
Who is speaking?
Who are you talking to?
To whom are you referring?
You gave my bonus to who?
Who is your wife?

One funny thing I've always found with grammar is people fight it tooth and nail. It ought to be right up our alley here in IT because we're used to strict syntax. And that's all grammar is. It's the syntax of the language you're using to communicate with people. When you want to communicate to a computer you use the syntax it understands.

You know, that's part of the reason people are misunderstood so much. They use such bad grammar that it makes the sentence ambiguous.

Of course, I, like everybody who knows anything about grammar, have to live in the real world. When I write, especially in my blog, everything isn't always perfectly grammatical. I try to add an element of style and write more like I talk. It tends to make it a little less stuffy, and easier to read. The general blog-reading public simply isn't used to some of the more complicated structures that you run into when you're making sure that the syntax is perfect. And truthfully, sometimes it sounds a little odd to me too.

I think the main difference that I'm trying to point out is that I choose to ignore the strict grammar sometimes so that I'm more readable to my audience, while those who don't know even this simple level of grammar don't have a choice. I always tell people you can break any rule you want if you have a reason.

OK, tomorrow I'm thinking about talking about the grammar of cursing... unless everyone wants me to stop the grammar lessons. I think it's necessary though for professional development. You should at least know the basics. I mean, afterall, you've been speaking English your entire life.

Posted by Sean McCown on January 11, 2007 10:05 AM


January 10, 2007 | Comments: (0)

Good IT Grammar

One of the things that's always gotten on my nerves is bad grammar. I'm not just talking about the little nitpicky stuff like split infinitives and dangling participles either. I'm talking about the big stuff that's so easy to get right.

When I first sat down to write this post I was going to preach to you about acting like a business professional, and that you can't expect the officers of your company to give you their kind of money when you can't even string 7 words together into a grammatical sentence. However, on further reflection, your board of directors doesn't know any more about grammar than you do, so it's all good. That doesn't mean however that you shouldn't at least try to learn a couple simple rules to make yourself sound more like you've been speaking English for longer than a year or two.

So here are a couple simple rules that you can't live without.

When to use I:
Nobody seems to know when to use I and when to use me. I'm always hearing things like this:

Jim called Tammy and I into the room.
He gave a piece of gum to both Tammy and I.

Those are of course both completely wrong. The grammatical way to say that is:

Jim called Tammy and me into the room.
He gave a piece of gum to both Tammy and me.

OK, so how do you tell the difference? How do you know when to use I and when to use me? Well, it's easy, I is subjective, and me is objective.

What that means is you use I when it's the subject of the sentence, and you use me when it's the object of something... like an action... more specifically, when it's the object of a preposition (more on that in a minute).

So what does that really mean, here are a couple examples.

I like pie. I is the subject.
He gave the pie to me. Me is the object of the action. Me receives the pie.
Tammy and I like pie. This time both of us are the subject.
He gave the pie to Tammy and me. This time both of us are the object.

So the easy way to know when to use I or me with multiple subjects or objects is say the sentence to yourself first with you as the only participant. Now, whatever you use with only yourself in the sentence is what you use with multiples.

So if you say:

I like pie. Then you have to say...
Tammy and I like pie.

If you say:

He gave me some pie. Then you have to say...
He gave Tammy and me some pie.

You could never say:
He gave I some pie.
Therefore you can't say:
He gave Tammy and I some pie.

OK, I was going to give you a couple more, but I know how people tend to glaze over when you start talking about grammar.

Take this one and see how you do with it. If you like it, let me know and next time we'll work on who and whom.

Posted by Sean McCown on January 10, 2007 07:02 PM


January 09, 2007 | Comments: (0)

Don't Be A Tool

Those of you who follow my blog know that I'm big on DBAs having something to offer your company other than just being an insurance policy should the DB ever go down. You should actually try to make things better for your users.

One thing I like to do is pretend everyone in the company is an external customer, and I'm a contractor. As a contractor, my income depends on how much business I can bring in. So, while I'm talking to users, I see what I can do to drum up their business. If I hear someone talking about an Excel sheet they do every month, I ask them questions about it to see if it's soemthing that could be brought into the DB to make their job easier. I'm amazed at every company I see how much stuff is still done by hand every month/week/day.

You don't have to wait to overhear something either. You can just ask random users, or send an email to the dept heads. Ask them if their people have any processes that they do by hand that they would like to look into automating. I did that a few times in my last company and it worked out really well. We had a girl who was spending 3hrs every week going through user ids that hadn't logged into an application in a while and sending them emails asking them to change their passwords to maintain compliance. She had over 200 names to go through, and that many emails to send. I know what you're thinking already... there's a better way to do it even by hand... and you're right, but what I did was brought it into the DB and just had it go through every fri and start sending out emails. Once we got that working (2days), the word spread like wildfire and I had more business than I knew what to do with.

The point of this is that a lot of DBAs are tools. They don't go out and drum up business, nor do they care to. You never see a hammer running in to offer its services do you? No, you have to go get it when you need to use it. That's because a hammer is just a tool. And you want to be more than that.

Posted by Sean McCown on January 9, 2007 10:34 AM


January 04, 2007 | Comments: (0)

Take a Safari

Last fall I acquired a subscription to Safari Books Online. At first I wasn't sure what to think. I was a little skeptical thinking, well, this is just another online book repository where you can find all the out-dated IT books. That's not the case at all!!

Safari books is without a doubt the only IT book reference I would recommend thus far. In pretty much every IT shop I've worked in, there's always a push to collect an IT library for the staff to check out. The problem with that is it constantly costs you money, and of course, only one person at a time can read any one book.

Safari has so many books I can't even count, and from several publishers. I'm not being paid for this endorsement. I use Safari and I love it. It's got so many new releases like Ken Henderson's new book, and a SQL Server 2005 training kit from MS Press. And while I can find IT books out there that aren't on Safari, their list is so extensive and so impressive, you won't want for any topic.

So if you're looking to build an IT library, you really can't go wrong with Safari. You can add selections to your bookshelf and even bookmark your spot and make notes. I only wish you could download some of the selections, but somehow I think that wouldn't be beneficial to Safari. Well, actually, you can download individual chapters so I suppose eventually you'll get the entire book if you want it. All the same though, I really can't say enough about the service.

One of my favorite features is the search. You can search a book for a topic, or you can search ALL books for a topic. I just love that feature. I remember searching a book for a particular piece of code on SQL Server 2005, and it wasn't in the book I was reading at the time so I searched the entire library. The result set returned was pretty big, but it only took me about 5 mins to find what I needed.

OK, I'm bordering on over-talking it, so I'll shut up now. I just wanted to pass along a good resource while it was on my mind. As IT libraries go, you can't go wrong with Safari.

Posted by Sean McCown on January 4, 2007 07:36 PM


January 03, 2007 | Comments: (0)

Time to Get Yours

The topic of pay scale has smacked me in the face once again. I realize that some careers just natuarally pay more than others, but sometimes it's just ridiculous. I recently read another article where a big company executive was given a $35mill. bonus. What the hell?!?

OK, being in IT there aren't many opportunities to do whatever it is that these guys think they do for this kind of money, but I, and a few others I know have come pretty close a few times. I've personally saved companies hundreds of millions of dollars over the course of my employment, and what kind of bonus do I get? I usually get the standard 5-6%... just pathetic. Now, I realize that if pressured about it, these guys will tell you that they make the company a lot of money with their decisions, and they can show you an actual profit margin that they've effected. However, if a penny saved is a penny earned, then I've got a profit margin to show too. Why doesn't my bonus reflect the money I've made the company by saving them license fees, and server costs? Why does the executive who says we need a data warehouse get a HUGE bonus for coming up with the idea, and the guy who puts it together and makes it work gets almost nothing? I guarantee you that in this sense, the DBA is just as good as his bloated executive. Do you think a DBA couldn't come up with the idea of a warehouse? Of course he could, and in fact, he's probably been telling the company for months they needed one. The difference between the two is that the DBA can code his own ideas while the executive it merely a windbag without his IT staff.

I've made decisions that have kept companies out of lawsuits, allowed them to service more clients to generate tons of extra revenue, and even gotten HUGE refunds on bad software that had been purchased over a year prior. And in all of these decisions, there's not a single board member I've ever worked with that I could even explain these things to in an entire day. Don't get me wrong now. I realize that every ship needs a good captain, and a company needs good leadership, and these guys are necessary. The decisions and deals they make give all of us our jobs. But it's time you guys stopped burying your heads in the sand and pretending you're the only ones who make the company millions. It's funny isn't it? Your bonuses are merited on the money you bring in and safe, while mine is based on how much I shut up and do my job. As long as nothing breaks, or the breaks are fixed in a timely manner, I'm expected to sit here at the kids' table when the bonuses are handed out.

I've blogged before that DBAs don't get any respect because it's not good enough to be excellent in our jobs, we also have to know the business side of it, and many companies are sending us to business school to make us more useful to the business, and not be just a bunch of dumb bit jockies. Well, here we are guys... making business decisions that effect your bottom line. Now that you've drug us into the business side of things, it's time to start giving us those business-level bonuses. You can't have it both ways. Eventually the DBAs are going to wake up and start telling you no. No, we won't put up with the lower salaries. No, we won't put up with the lower bonuses. No, we won't work all night, and every holiday while you sit at home and ignore your family so you can count your money. Hey, we want to ignore our families too.

So it's time for a reform. DBAs are no longer the janitors for your bad decisions. Your business is completely dependent on your databases, so it's really high time you realized that keeping us around for a long time is worth your while. And it won't be too long before the general DBA community wakes up and discovers that we're making huge decisions and saving the company thousands, if not millions, and we deserve some of that big bonus money too.

Think about it, or you'll find yourself in database school trying to figure out how to get your systems back up, and wishing you'd listened while you had the chance.

Posted by Sean McCown on January 3, 2007 10:07 AM


January 02, 2007 | Comments: (0)

OpenSource Blues

Hey guys. It's been kind of a long holiday for me but I'm back and mostly no worse for the wear.
You may remember before when I was talking about auditing and my talk with a vendor, and that I promised to talk about OpenSource DBs in this area. Well, here goes. And here's the original post for your reference.

One of the things that gives me great pause about seriously counting on an open source DB for important data is that fact that you're basically running blind. Take MySQL for example. I've never seen any real auditing functionality which means that you have no visibility into what's really going on in your DB. I can't imagine there being an auditor that would pass you on anything really important on this platform. I like MySQL for what it is, but let's face it... the open source DBs just can't compete with real enterprise-level products when it comes to features. I've said many times that they have several holes in their functionality. You also can't parse their logs. That means that there's no way to pull back transactions, or even audit activity in that fashion, which is one of the main ways the vendors do it.
I'm even still waiting for MySQL to get some performance counters.

Remember, you get what you pay for, and I just don't think that the open source DBs are up to snuff when it comes to being audited.

You MySQL gurus out there... if I'm wrong let me know and I'll print a retraction.

Posted by Sean McCown on January 2, 2007 10:37 AM


Technology White Papers

 

InfoWorld Technology Marketplace

  • Virtually Limitless Virtual Storage - Do you need virtualization space savings of 50% or more with virtually no performance impact? You might be able to get storage...
  • Invisible IT? - The goal of IT is to become an invisible entity within a larger organization. Eliminating visibility and road blocks IT ...
  • It Really Is Easy to be Green - "Green IT" is a popular concept. And IT organizations are learning the influence that IT purchase decisions have on data...
  • Key Strategies For SOA Testing - SOA requires a unique approach to testing. Unless you're willing to reorient your testing procedures and technology now,...
  • Eliminate Botnet Security Risks - Botnets are widely regarded as the top threat to network security. This Whitepaper explains how botnets have traditionally...
  • Zero Day Protection For Your Network - Zero day attacks are a growing threat because they pass undetected through conventional signature-based defenses. Rather...

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert

Find out when the latest white paper is available:
 
 
» BUY A LINK NOW

Sponsored Technology Links