Dec 142010
 

This month is the (lucky) 13th T-SQL Tuesday and is being hosted by Steve Jones (blog | twitter). Steve is asking about issues we’ve had interacting with a business in order to get the job done. Specifying project requirements often leads to the classic problem of “do what I meant, not what I said!”. In my opinion, a lot of it deals with the spirit of what the business means. Here’s a few examples:

The business might mean well, but not know what they’re talking about. A while back I applied for a DBA position where the job description made it very clear that familiarity with transactional replication was essential. The interview reflected this as well, and a significant portion of it consisted of transactional replication questions. The interviewer explained to me that they have some rather “unique requirements” that make transactional replication essential, and proceeded to explain them to me. I told the interviewer that based on their description, snapshot replication may be more appropriate than transactional replication. They told me that the last DBA felt the same way, but the manager in charge explicitly specified to only use transactional replication. I’m willing to bet that the manager in charge probably only understood transactional replication, so they wouldn’t allow anything else to be used.

The business might not mean well. Once upon a time, my team was working on adding some enhanced options for users, including the ability to “opt-in” to receiving marketing emails. The conversation with management went something like this:

Mgmt: Let’s opt-in all the users to start with
Us: But then that’s “opt-out”, not “opt-in”
Mgmt: No it isn’t. We’re opting-in all the users automatically and letting them know they can opt-out at any time, so it’s “opt-in”.
Us: OK – let’s review the concepts of “opt-in” vs. “opt-out”…
Mgmt: We’re still going to opt-in all our users and let them opt-out if they want.

The business might not even care. I can think of a few times where I’ve been told to “just start coding” instead of taking the time to plan things out and do it the right way. After all, trying to think things through is just a waste of time, right? When I pushed back at management for this, I was told that “[their] bonus depends on getting things done, not getting things done correctly.”

I consider all of these cases to be “extreme”, but a great solution to many of these problems involves two-way communication. If both sides are talking and listening to each other, the chances of things getting to the point of ridiculousness are greatly reduced.

Dec 082010
 

SQL Saturday 67 LogoSQL Saturday #67 (Chicago 2011) has been posted on the SQL Saturday website!

Please Join Us!

We had an excellent turn out last year, and it’s looking like it’ll turn out that way again. Registration has been open a little more than a week and we already have over 100 registrations! Our limit is 400, so at the current rate you only have about 3 weeks left to sign up. Please visit the registration page if you’re interested! The event itself is free, but there is a $7.00 charge for lunch (not pizza!)

Why You Should Come!

  • The training is free! Even if you count the $7 for lunch, it’s still practically free.
  • Hear awesome talks from amazing people! We already have sessions submitted from a lot of great bloggers and even a few published authors. When the stuff they write is already awesome, imagine how much cooler it is in person! Think of it like attending a rock concert, except everyone has gadgets instead of drugs.
  • Networking! All those rockstars I just mentioned? They want to meet you. Really. Networking is a huge part of SQL Saturdays, and once you start meeting others who are as passionate about SQL Server and the database community as yourself, you’ll be hooked. SQL Saturdays are like crack bacon, and you will quickly find yourself wanting to go more often. Before you know it you’ll be looking for ways to finance trips to other events like the SQL Rally or PASS Summit

Call for Speakers

Whether you’re a seasoned veteran speaker or someone just starting out who hopes to become one, you’re invited to submit an abstract (or more than one if you like!) The call for speakers is open until February 24, 2011. YOU CAN DO IT!!

Hope to see you there!

Dec 012010
 

I’m sure this one’s been in SQL Server Management Studio for quite a while, but I never noticed it before now.

Let’s say you’re running a batch in SSMS containing 2 T-SQL Statements. For simplicity’s sake, I’ll do some selects from my Numbers table:

SELECT TOP 10 * FROM Numbers;
SELECT TOP 100 * FROM Numbers;

The “Results” tab appears with 2 result sets. The first has 10 rows, and the second has 100. The rows counter at the bottom right says “110 rows”. All of is exactly what I’ve come to expect. (Click on any screenshot to enlarge)

Row count for the combined result sets:
Screenshot

But wait, there’s more! If you click in the top result set, that counter will change to say only 10 rows. Click on the bottom set and it now says 100. Click back in the query window and it again shows the combined total of 110.
Screenshot

Screenshot

Nifty, eh? Again, I’m sure this is nothing new, just I had never noticed this behavior in SSMS before. Happy querying!