Applied Visual Studio Team System : SQL Server

Attending the PASS Summit

andy — Sat, 22 Sep 2007 08:33:00 GMT

Steve Jones makes some good points in his blog post Training. I find it difficult to believe the short-sightedness of some organizations when it comes to training events like the PASS Summit.

This year's Summit - like all previous years to date - had enough top notch presentations and labs to make it worth the cost of admission, travel and expenses, and the cost of allowing a database professional to leave work for three days combined. More than enough.

Like Steve, I don't get it.

Also like Steve, I bet we'll see these DBAs at the 2008 PASS Summit in Seattle - and working for another company.

I wonder if those responsible for denying database professionals opportunities for training factor in the cost of hiring and training a new DBA every six to eighteen months?

:{> Andy

Technorati Tags: EMPs Database Professionals PASS Training Changing Jobs

Getting Ready For The PASS Summit!

andy — Fri, 07 Sep 2007 21:31:00 GMT

The PASS Summit is less than two weeks away!

I'm getting ready for my presentations. I need a couple laptops to host virtual servers for the demos, so I bought some new gear to take with me.

Check out my Network-In-A-Bag!

It's a power strip, a couple CAT6 cables, power supply, and a NetGear 1G 5-port switch - all in a 1 gallon Ziploc bag.

:{> Andy

Technorati Tags: PASS Summit 2007 Networking

Iteration = Maturity

andy — Tue, 31 Jul 2007 14:01:00 GMT

Introduction

I was recently reminded that iteration matures software.

The History of Andy, Part 1

Like many DBAs, I was a software developer in another life. I built web applications - working my way up from HTML through DHTML and finally to ASP - and could regale (and bore) you young whipper-snappers with war-stories of how things were "back in my day". [/DanaCarvey]

But I won't.

The Times They Are a-Changin'

I'll share instead something I've witnessed many times since starting with software in 1975 - and something you probably already know: stuff changes.

And thank goodness stuff changes!

I recently ordered 1G of RAM from an online retailer. It should arrive before my next son (but that's not a given as Riley refuses to provide a tracking number - the doctors will induce Christy into labor Friday if he hasn't been born by then - but I digress...). I remember my neighbor John, who introduced me to computers, purchased a 256-byte RAM chip in the mid-1970s for about what I paid for the 1G. That's 256 bytes of RAM - not a typo. As I recall it was either a 14- or 16-pin IC.

Things have changed since then. Improvements in technology, brought about by building and improving upon existing knowledge, have brought us to a day when I can purchase 1,073,741,824 bytes for roughly the previous price of 256. I don't know how you feel about that. I think it's a good thing.

The idea of "building and improving upon existing knowledge" defines iterative development. Although the idea is relatively new to the software development field, it serves as the basis for engineering disciplines. Engineers iterate - build and improve upon existing knowledge - and we get more powerful hardware for the same amount of money. What's not to like?

Iteration - it's not just a good idea...

Iterative software development builds and improves upon existing knowledge within a specific domain. Most domains are defined by an application (wholly or in part), enterprise knowledge (again, wholly or in part), or - most likely - some combination of the two. For example, let's say you work for a large corporation as a software developer. Your domain could be the corporate website. In which case you possess knowledge about the business of the corporation and web development. You mix these together to do your job. In this case, you will probably pick up marketing savvy and current trends along with the latest AJAX techniques.

As you make successive passes (iterations) through the website design interacting with marketing, your domain knowledge is built and improves. As your domain knowledge increases, the website will become more valuable to the corporation - as will you.

Iteration adds value.

Got Iteration?

The same can be said for database development.

Perhaps you've experienced this in your own database development efforts: you receive a request for a database design to meet some desired functionality. Or you're handed a design and asked to optimize it. Or maybe even you had an idea to capture data - performance metrics or something similar - and you're designing a database solution to accomplish this.

You get into the development a few hours or a few days and realize a little tweak here or there would improve performance, or readibility, or better adapt the design to your intentions. So you make the tweak and continue.

This improvement leads you to re-examine other portions of the design and you make more tweaks. Maybe your last change broke things. Maybe you see an opportunity to add a parameter to a stored procedure and combine the business logic of three stored procedures into one.

A "Growing" Solution

Pretty soon, you have iterated enough to feel comfortable promoting, integrating, or even releasing the results - letting the effort move to the next step.

Depending on the nature of your efforts, it may not end there. If your database development is the back end of a larger application - say, the corporate website, for example - there will likely be requests for changes over time as the site grows (scales) in complexity and size.

When the requests come in you are not likely to start over. You will most likely build and improve upon your existing knowledge. You will most likely iterate.

Scaling forces iteration.

Voilà

This is how solutions mature - be they applications, databases, or both - regardless of who writes them or how many are involved in the development effort. It doesn't matter if the development team is one lady in a cubicle in the European Union or a development team of thousands at Microsoft.

Iteration matures software.

:{> Andy

Meltdown!

andy — Wed, 04 Jul 2007 19:46:00 GMT

A couple days ago the Vista Ultimate instance on my laptop when all Klingon on me: it was "a good day to die."

I'll never know why for sure. Indications point to COM+ and VMM giving up the ghost. They were good systems, may they rest in peace.

I tried to revive the old OS. It would run in Safe Mode and even Safe Mode with Networking, but that's just not the same as having all the functionality I know and love.

I've spent the last couple days (and nights) rebuilding a second instance of Vista Ultimate on the same machine. I'm about half done at this point. Today is SQL Server instances and Visual Studio Team System day.

It's not just the installs, there's the service packs and updates after the installations. Lots of installing.

But it's also an opportunity to rebuild the machine with a different configuration.

Back to installing...

:{> Andy

Technorati Tags: Vista Re-install

SQL Server 2005 Books Online Update

andy — Sat, 16 Jun 2007 18:44:00 GMT

There's an update to SQL Server 2005 Books Online available.

Major changes include information regarding installation of SQL Server Express SP2 on embedded systems and updates on the WITH ENCRYPTION topic.

:{> Andy

Technorati Tags: SQL Server 2005 Books Online

RowCount and Stored Procedures

andy — Thu, 07 Jun 2007 13:23:00 GMT

Recently I thought the SQL Server RowCount functions were lying to me - telling me there was only one row being returned by stored procedures that performed Select statements only - Select statements that I knew returned more than a single row.

I discovered the culprit after some digging: the Return statement at the end of the procedure was, in fact, returning 0 - which is technically one row.

:{> Andy

Technorati Tags:

SQL Server 2008 CTP Available!

andy — Wed, 06 Jun 2007 20:29:00 GMT

The June CTP of SQL Server 2008 (the database server formerly known as Katmai) at Microsoft Connect!

Registration is required. You must also complete a three-question survey.

:{> Andy

Technorati Tags: SQL Server 2008 Katmai CTP

Notes On Project Success - Part 2, to Stake-Holders

andy — Wed, 06 Jun 2007 07:01:00 GMT

Yesterday, I addressed Technologists regarding Project Success; today I address Stake-holders.

I have participated in projects that have succeeded and in projects that have failed. One thing I noticed about the failed projects: expectations were poorly - or not - managed.

What are examples of project expectations?

Functionality - when completed, the application / upgrade / database / server will allow me to perform xyz.
Time - how much time one expects to develop the functionality. Can also include a schedule for deliverables and / or milestones.
Expense - how much one expects to pay for the functionality.

As a stake-holder you know what you want. And you can probably communicate your expectations - using the three areas above as a guide - effectively. Issues arise when, for whatever reasons, there is a disconnect between your expectations and the those of the IT team tasked with performing the work.

I've witnessed several unsuccessful executive responses to the disconnect scenario:

"Ostritch" - ignoring the disconnect in hopes it will disappear with time.
"Gambler" - belief that there's a big score (project or technical break-through) just-around-the-corner that will save the day.
"Taskmaster" - belief that threatening people is the way to motivate them to work around challenges.
"More-Resources" - a firm belief that more resources can solve any problem known to humanity. (I often imagine these folks live in subdivisions and get their neighbors to help mow their lawns. In my mind I see forty push-mowers aligned wheel-to-wheel along one edge of a lawn. On signal, they all puch across the lawn, mowing it from end to end in a single pass...)

I worked for a company that decided to employ Performance-Based Management techniques to a successful team. They actually applied the concept company-wide, regardless of whether the teams were successful or not. In this particular flavor of PBO, 20% of employees were considered outstanding, 60% were satisfactory, and 20% were acceptable losses that the company would be better without. These numbers were set in stone and never changed.

My questions were:

Who failed? Did HR fail 80% of the time by hiring mediocre to poor employees? or did our management disillusion and de-motivate these people into their non-excellent state?

Are we, in effect, planning to never get better?

Statistical control works on processes, not people - at least not well on people.

So what is the solution?

Communication.

It's that simple. Executives have to either be approachable by the IT team or someone representing them, or you must appoint someone to be approachable in your stead. Leadership dynamics (or just plain scheduling issues) may require you to appoint someone. If so, try to find someone who speaks both business and technology.

Realize that sometimes you do not know what you do not know. I run a couple small corporations and have an appreciation for the amount of work involved in merely administering such an entity. I also know technology changes every day. It's difficult for anyone to keep up - especially if you're minding stock-holders, regulators, and the lot. We may have moved beyond the technology you understand. If we haven't, we will soon.

Either hire people you trust or trust the people you hire. If someone violates the trust, respond accordingly. But do everything within your power to exude trust-worthiness as well as trusting-ness.

For truly innovative people to be free to succeed, they must first be free to fail.

The best tools were once toys. IT professionals are notorious tinkerers. You will be astonished at the return on investment for a weekly-scheduled hour of "play time" for developers.

:{> Andy

Technorati Tags: Software projects Success Failure Technologists

Notes On Project Success - Part 1, to Technologists

andy — Tue, 05 Jun 2007 07:01:00 GMT

There was a very interesting article posted not long ago at SQL Server Central by Janet Wong entitled My Projects Have Never Failed.

In the article, the author explains projects that experienced varying degrees of success for various reasons - but in all cases a disconnect existed between the end-user or customer expectations and the delivered product.

Personally, I consider these projects failures.

Here's why: The stake-holder or executive has this expectation. It may be very unrealistic, but they hold it nonetheless. They may be very educated people or not. They may understand technology or not. None of this impacts the fact that they hold expectations.

Q: Who's in charge of communicating realistic expectations?

A: Technology people.

Or at least a member of the technology team.

A good technology team has several moving parts and people fulfilling different roles.
Note: If you're a one-person-show, this post is not about you.

At least one person on the team needs to be customer-facing. That person needs to be an expert in communicating with business people who hold unrealistic expectations. Make no mistake: this is a talent and an art.

Good communicators are rare in life, rarer in business, and practically extinct in the technology sector. Most good communicators abandoned IT departments decades ago and moved into sales where they could enjoy salaries orders of magnitude beyond what IT departments will pay them. But I digress...

I don't blame my customers when their expectations go unmet - I blame myself. Had I communicated something better - or even differently - the outcome would likely have been better for everyone.

So here are some tips for communicating with project stake-holders / executives:

You may understand what you mean when you say "Third-Normal Form Relational Database" at a meeting with executives, but few of them will. It's not their job to understand - that's why they're paying you. Step up. If you cannot translate your conversation into executive-speak, let someone else do the talking. If your point is to embarrass the executives, you'll probably not try that at your next job.
Identify someone on your team (or add someone to your team) to serve as a point-of-contact to the executives. If your team has a project manager, they may be the best person to do this. I've also seen horrible project managers who exacerbate the problem with their own inability to communicate (or worse yet, take the side of the stake-holders and hang the development team out to dry).
Keep it short.
Keep it as simple as possible. Stake-holders and executives do not need to know the history of iterations you went through to arrive at your conclusion. Take it as a sign of confidence in your abilities that they accept your judgment on the matter.
Stake-holders and executives have different priorities from you and I technology people - remember that.
If you deliver quality late, no one remembers. If you deliver junk on time and under budget, no one forgets.
The old consulting axiom ever applies: Under-promise, over-deliver.

This is business. This isn't academia; you do not get to interpret your own results.

It's not a success unless they believe it to be a success.

Me, I've had projects fail. Some of them have been spectacular in the scope of their failure. To date, I've stepped up, admitted the failed status of the project along with my errors, and promptly moved to correct the issues. I've found excuses to be a waste of my and my customer's time.

Having a project fail is bad enough; failing to manage the failure takes it to the next level.

Remember, if you fix it, it will be ok.

Tomorrow, I address Stake-holders.

:{> Andy

Technorati Tags: Software projects Success Failure Technologists

Managing The Thing You Cannot Touch

andy — Sun, 27 May 2007 07:01:00 GMT

Yesterday I wrote about The Thing You Cannot Touch. Today I'm going to tell you some ways to manage the situation.

First, try to determine why You Cannot Touch The Thing. This is invaluable information in charting the waters ahead - especially if you're consulting.

Second, accept the fact that there's better than a 90% chance that you will not, in fact, be allowed to Touch The Thing. In my experience, three things must be true for you to overcome the business friction imposed by The Thing:

You have to try everything else first.
Everything else must fail to sufficiently address the issue.
The source of the issue must be mission-critical.

Regardless, your best knee-jerk reaction is acceptance. This is tough for a professional. In your heart of hearts you know what it takes to solve the real issue. And yet, you've been told You Cannot Touch It.

The good news? There's also a better than 90% chance you can find a way to solve the issue - or at least alleviate the client's pain - without Touching The Thing.

Modern enterprise applications are comprised of lots of moving parts. The Thing is probably not the sole source of pain. Addressing other bottlenecks may do the trick - at least for now.

And, if you're the person they called last time they had an issue and you solved it (and weren't "difficult" to work with), you'll likely get the call next time.

How cool is that?

:{> Andy

Technorati Tags: Consulting Software Development Satisfying The Customer Leveraging New Business

The Thing You Cannot Touch

andy — Sat, 26 May 2007 07:01:00 GMT

I have this theory about consulting. I call it The Thing You Cannot Touch. Since a few friends have found it amusing I thought I'd share. It goes like this:

A potential client contacts your firm. A conference call is arranged to discuss the issue. During the call, the issue is defined. Resolution theories and attempts to date are shared, along with their results. The current status is explained - along with

The Thing You Cannot Touch.

Sometimes an attempt at justification accompanies the announcement: "We know it can't possibly be _______ so we're not going to waste any time looking at it."

Other times, it's just put out there for what it is: "You can't touch _______."

My experience has shown the heart of the issue almost always lies with The Thing You Cannot Touch. It needs to be fixed but someone, somewhere, for some reason does not believe it to be so - and so it Cannot Be Touched.

Sometimes it's political - It's someone's "baby". They built this application just ten short years ago - worked nights and weekends and toiled and sweated and bled to make it work - and rode it all the way to CIO, after all. Who are you, lowly consultant, to tell them VB 6 code should be re-written in this new fad known as .Net? Doesn't Vista support VB 6 until the mid-20-teens?

Sometimes the decision-maker doesn't understand the differences in the technologies.

Sometimes it's a purely market-driven business decision - and the decision-maker is right and justified in choosing to keep hands off The Thing. It's not all about technology folks... it's sometimes about what I like to describe as the (little "s") software (big "B") Business.

If you find yourself on a consulting conference call and The Thing You Cannot Touch comes up, pay attention. Tomorrow I tell you how to Manage The Thing You Cannot Touch.

:{> Andy

Technorati Tags: Consulting Software Development Thing You Cannot Touch Old Code Outdated Code VB 6

Benefits of 64-bit SQL Server

andy — Fri, 25 May 2007 07:01:00 GMT

There's an interesting post out at the SQL Programmability & API Development Team Blog about 64-bit performance enhancements entitled Will 64-bit increase the performance of my SQL Server application?

Interesting stuff - a recommended read.

:{> Andy

Technorati Tags: SQL Server 2005 64-bit performance improvement

SSIS Design Pattern - Incremental Loads Post Now Live at ABI

andy — Thu, 24 May 2007 07:01:00 GMT

The latest in my SSIS Design Patterns series - SSIS Design Pattern - Incremental Loads - is now live at Applied Business Intelligence!

:{> Andy

Technorati Tags: SSIS Design Patterns Incremental Load Business Intelligence ETL BI

Tim Tatum's T-SQL Presentation

andy — Sat, 14 Apr 2007 05:46:00 GMT

Tim Tatum did a great job presenting to the Richmond SQL Server Users Group last night! Last night's meeting also set a new attendance record - it was a great night.

Tim thought his topic wouldn't be well-received since most of our presentations focus on SQL Server 2005. Truth be told, there's still quite a market out there for SQL Server 2000. The platform is stable and still meets the database needs of most organizations.

SQL Server 2005 performs better, is more scalable, and has some very interesting and useful features. Not all organizations have a need for SQL Server 2005, and some will not upgrade until mainstream support ends in less than a year.

:{> Andy

Technorati Tags: sql server Tim Tatum Richmond SQL Server Users Group T-SQL

SQL Provisioning Tool (SQL Server 2005 SP2)

andy — Fri, 06 Apr 2007 05:24:00 GMT

At the end of the SQL Server 2005 SP2 installation you may be prompted to launch the SQL Provisioning Tool. This utility makes members of the local administrators group SQL Server sysadmins - which is cool, especially if your instance security is Windows Authentication only.

If anything "bad" happens during the provisioning process, the utility simply shuts down.

By "bad" I mean things like the tool attempting to access a service you shut down. Note: you may have shut down this service because you were prompted the file was locked during an earlier step in the Service Pack installation.

When you search for the Provisioning Tool in the Start Folders you will note it isn't there.

You can find it with diligent searching (or by reading this blog): It defaults to [Installation Drive]\Microsoft SQL Server\90\Shared\SqlProv.exe. On my machine I installed SQL Server on the C:\ drive so my path to SQLProv is "C:\Program Files\Microsoft SQL Server\90\Shared\SqlProv.exe".

Re-executing the tool doesn't seem to cause any negative impact, but I haven't conducted rigorous testing.

:{> Andy