Category: Editorial

  • Savvy Managers

    ETL
    A good manager knows a bit about what you do, but not necessarily the details.

    Today’s editorial was originally released on Nov 27, 2007. It is being re-run as Steve is at the PASS Summit.

    My guess is that most of you out there wouldn’t necessarily classify your managers as “savvy”, especially as it relates to data. I know that when I hear managers talking about “data quality”, “data integrity”, “ETL”, or any other acronyms, I tend to cringe, expecting more work, with poor requirements, and likely unreasonable estimates.

    But not all managers are that bad and when I attended the Micosoft BI Conference earlier this year, I was surprised to see so many business people, especially managers, there and talking about how much value they got from BI because it gave then more insights into their data.

    And they almost universally talked about how important a strong data warehouse with high data quality is to the success of a project.

    Data quality is important, but it takes an effort to ensure that you can achieve a high level of quality in your data, meaning that the data is accurate and represents what you think it represents. I caught this interesting article about 10 data quality habits for successful managers. It probably should be for successful organizations and not just managers, but it’s a good guide for managers to be aware of. Without reading the article, I’d bet you could guess at what some of the items should be. They’re mainly common sense, but they bear repeating and it’s good to see them listed in together in a short article.

    Data quality takes effort and just like programming, the earlier you can introduce checks and catch errors, the less expensive it is to maintain. However that doesn’t necessarily mean that you should go all the way to the source. Putting in a huge amount of checks and filters in the input client might not be in your best interest.

    Consider a salesman, trying to make a sale, entering data and constantly getting pop-ups and errors that force data entry to be exact. Can you imagine how frustrating this would be? And possibly how this might impact data quality? Can you guess at what percentage of people might get names entered as initials instead of misspelled names? Does someone need to be slowed down because they typed “Bbo?”

    Enforcing data quality at the source might be better served with suggestions or filters that try to fix common mistakes or even batch up confirmations of suspected errors for someone to examine later. There are any number of ways to make this an easier process and still ensure data quality.

    My advice is that you should tackle data quality as an ongoing part of your job. Make constant, continuous, and small improvements, build in checks and balances, and be sure you work with other groups and users to ensure the load is shared, and more importantly, easily integrated into the way they already do business.

    And maybe I’ll see you featured at one of the next BI events as a SQL Server success!

    Steve Jones


    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are now available atsqlservercentral.podshow.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.

    The RSS Feed:  or now on iTunes! 

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo atwww.everydayjones.com.

    I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.

  • Unprotected Queries

    SQL Injection
    SQL Injection is a constant problem in many applications.

    Today’s editorial was originally released on Dec 4, 2007. It is being republished as Steve is at the PASS Summit.

    This is absolutely amazing;over half a million database servers have no firewall. How can you put up a database server, SQL Server, Oracle, DB2, even MySQL, without a firewall?

    How can you put any server on the Internet without a firewall? Even most home routers enable a NAT router and basic firewall these days, not allowing connections in by default. In the last 5-6 years, the technology has been widely available, even to uninformed home users, to not deploy any system on the Internet without protection.

    So how do these servers get out there? Are these development systems? Are people opening 1433 so they can test an application or access their remote SQL Servers? That’s what I suspect. Many developers I know are optimists and they don’t expect people to be pinging their servers or accessing their systems in any way other than how it’s designed.

    We’ve been hacked here at SQLServerCentral.com a few times over the years with SQL Injection techniques, but never to my knowledge with an attack directly against our SQL Server. For a long time we did have our SQL Server exposed, but not on 1433. It was on a high, random port that was unused by any other service and we had strong passwords on accounts. It was a convenience service, we had login tracking, and I never saw an unexpected attempt in our logs.

    However if you run a corporate SQL Server and need to stick servers outside your firm’s firewall in some type of DMZ, at least close off port 1433 to anonymous access. Go spend the $100 out of your pocket for a small router that can at least protect your servers with basic NAT and prevent traffic from getting directly to your database server. It might not be the best solution, but it’s better than nothing.

    There’s no excuse these days for putting a server out on the Internet without at least basic NAT protection. Some type of router or firewall should protect every server, and probably every computer, and only allow those services that are really needed. For most servers, this is port 80 and nothing else. Allowing access to SQL Server, RPCs, or any other port that’s not meant for anonymous access, is really stupid.

    And if you can’t figure out a way to securely make your service available to partners or customers, then you should hire someone that can. There are plenty of networking professionals out there that can help you set things up correctly.

    Know your limits, ask for help, and don’t jeopardize your company’s security because of ignorance, pride, or laziness.

    Steve Jones


    The Voice of the DBA

    Wakamojo

    The podcast feeds are now available atsqlservercentral.podshow.comto get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted. You can get feeds from there.

    Today’s podcast features music by Wakamojo, the Kansas band featuring our very own Adam Angelini, DBA from the heartland and SQLServerCentral.com community member.

    I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.

  • Working Your 40

    part time image
    Will you be a part timer at some point in your career?

    Today’s editorial was originally released on Dec 3, 2007. It is being republished as Steve is at SQL in the City in Seattletoday.

    Or will you be working your 35, 30, or even 20?

    I saw this article about a report from Gartner that by 2015 many of us will work less than 40 hours. As someone that’s had some success in IT over many years, I could actually see this happening.

    Not I, you say. They can’t mean IT workers. Perhaps those secretaries, accontants, marketing folks, and others will negotiate less work per week, but not with those in IT. We work long hours to meet deadlines and have large workloads, on-call and after-hours work, and more.

    IT has been one of those areas that has really slipped between the cracks with regard to employment laws and customs in my opinion. We’ve almost been treated like blue-collar workers but paid and expected to work like white collar workers. Add to the fact that most of the time the average person can’t understand what we really do or see the results of our work until it’s finished, and IT workers haven’t really been easy to classify.

    But in my opinion we have one huge advantage over many other types of workers: we can work anywhere.

    I’m not sure we’ll get better staffing at companies or even lower workloads. But I can see our “core hours”, those times where we have to be in an office, or available for phone calls, shrinking below the 40 hour mark. Especially as telecommuting grows, I’m sure we’ll have less and less structured time in the office.

    Initially I would guess that many of us will make up shortfalls with work from home, after hours, on-call, and other methods. I know I typically work 40-50 hours, but it’s 7 days a week, and spread out in 2-3 hour segments throughout those 7 days. I’m as likely to be working Saturday morning as Tuesday afternoon, or even late Sunday night.

    I do think that the 20 hour job that is described in the article is interesting, and if someone can figure out how to balance the work and communication in a company, it would be a great idea. How many parents that don’t work would love to apply for a “20 hour, full-time job”, while their kids are at school? In Colorado, we have a number of “year round schools” where the kids go to school for 9 weeks and are off for 3, in four quarters. A few employers have taken advantage of this by balancing 4 workers for 3 slots, knowing that one of them is always off from work, taking care of their children during a break.

    I can certainly see that this would be a boon for DBAs. I’ve seen plenty of DBA production jobs that could be handled most of the time in a 20 hour week. Short term consulting could help those crisis situations and if they pay was in the 50-60% of the current range, it would be interesting to me.

    I just wonder how many of you would be looking for 2 20-hour jobs. I know I would.

    Steve Jones


    The Voice of the DBA

    Robin Stine

    The podcast feeds are now available atsqlservercentral.podshow.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted. You can get feeds from there.

    Today’s podcast features music by the beautiful, jazzy, Robin Stine. Check her music out at www.robinstine.com.

    I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.

  • A Welcome Delay

    Always delay before you send an email, especially a strongly worded one.

    This editorial was originally released on Nov 30, 2007. It is being republished as Steve is traveling to the PASS Summit.

    Microsoft got in on a deal to Nigeria that Mandriva Linux negotiated with the government there. The story almost sounds like a bad email: the provider of a “free” product complaining that another company gave their product away for free? So does that mean that in a free market where the cost is the same ($0), that Windows is superior?

    There’s some other editorial on that topic, but in this case, what was interesting is that the CEO of Mandriva fired off an open letter to Microsoft, which you can read here. The tone of the letter was a little whiny, and it didn’t seem as though Mr. Bancilhon really thought through what he was writing.

    It’s Friday, and with the holidays approaching, I thought this would make a good poll.

    Do you pause before sending emails?

    In the old days, back when I was younger, if you wanted to fire off a letter, you had to write it and then mail it, usually ensuring some type of delay. Often you had at least one night to think about what you’d written before you dropped it in a mailbox.

    There are plenty of people that still recommend that you delay sending an emotional email for at least a day. I know quite a few people that rethink their position before sending, often saving the email to a drafts folder for ten minutes, an hour, some delay to give themselves a break between writing and proofing.

    I’m actually pretty bad. As I’m sure many of you have noticed, typos slip through the editorials from time to time, often because I’m in a rush. My self-proofing skills aren’t the greatest, and I tend to make mistakes more often than I’d like.

    However I’ve also learned that delays can be good things. I’ve often incorporated a delay in restoring a secondary log-shipped database to give me the chance to recover from an accidental deletion of data. Delaying the send of a potentially inflammatory email allows me the time to cool down and can prevent me from making a big mistake.

    Email is quick and a great tool, but it shouldn’t be abused. Take the time to be sure that the message you’re sending is the one that you want received.

    Steve Jones


    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are now available at sqlservercentral.podshow.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.

    The RSS Feed: or now on iTunes!

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.