It Depends

Why Format TSQL?

Recently I had the chance to help a student debug a problem on a production server. It appeared to be failing because duplicate uniqueidentifiers were being created. Thinking that unlikely because the G in GUID stands for global, we dug in but found the code painfully hard to follow due to poor formatting, mainly the indents. She didn't own one of those 'prettifier' tools, so we used my old standby Instant SQL Formatter, an online formatter that does a reasonable job of formatting TSQL at a great price - free! Note: I have no ownership or other interest in the site. Many scoff at making code pretty, but especially with a tool to do it for you it can really make life easier for the next person.

And the answer to the problem? The GUIDS were fine, there was a fall through case that had an incorrect error message, and that in turn was being caused by a data problem.

Volunteering

Recently I was visiting with an old acquaintance and one of the topics that came up was volunteers. At some point in the past I had said something about volunteers that subsequently proved true (hey, I am right sometimes!) and based on that, he was crowning me the know-all person on volunteers and suggested I write a book about it. I'm a bit more modest and realistic, there's a lot I don't know about volunteers. What I do know I've learned from volunteering here and there as well as learning to use volunteers for oPASS and for SQLSaturday. But the conversation did remind me of one my rules; if you want to know read the book. So I ordered two from Amazon, Volunteers How to Get Them and How to Keep Them, and Volunteers Wanted. Both were good, but I liked Volunteers Wanted better and it's a great value at $10.99.

It's an easy read, but there are a lot of lessons in that little book and the hard part is thinking about all the things you should be doing better as you go. It's obviously written from the perspective of the organization that needs volunteers, but it wouldn't be a bad idea to read it if you were considering volunteering so you have some idea of what drives the process.

Maybe I'll make up a mini poster one of these days, but for now here are my basics for managing volunteers:

• Build specific tasks/time frames and then ask for volunteers
• Follow up and don't get frustrated if they haven't completed the task, just leave time to reassign or handle yourself
• Say thank you often and personally, and make sure the group knows of their efforts

My follow up project is to get someone to read the book and give a 15 min presentation at an upcoming oPASS meeting. That should get some interest in the topic going, and of course point out the flaws with my current efforts to manage/recruit volunteers!

SQLSaturday Call for Speakers - Cleveland & Olympia

Call for speakers is open for SQLSaturday #5 in Olympia, WA on Oct 10 (note that the MS BI conference is in Seattle earlier that week if you're going you might consider staying over a day or two) and for SQLSaturday #6 in Cleveland on Aug 9th. First time events in both cities and they are looking for a good variety of speakers. If you live in the area, or know someone, give them a nudge!

Registration is open for both events, and early registration is open for SQLSaturday #7 in Birmingham, slated for the first week or two of March 2009!

Employee or 1099?

My friend Wes Dumey does a lot of work in the business intelligence sector as a contract employee and has a post worth reading called The Great Debate - Employee vs. Consulting. I don't agree with all of his points, but it's an interesting conversation to have. I do agree that too many of us seem overly focused on benefits, rather than just looking at the dollar value of the benefits and adjusting the wage accordingly. For example, I pay about $6k a year for health insurance for my family. It doesn't matter if I make $100k and get free insurance, or make $106k and pay my own, I net the same (assuming benefits are comparable/reasonable). The challenge is that employers have to put everyone in the insurance pool to get the rate, and so as an employee you can't negotiate for that extra $6k easily (and the same for the 401k match). But as a contractor, all doors are open - you just have to understand your own costs, financial goals, market value, and then ask!

I don't want to comment much until Wes does part 2, but I'll finish with this; most of us prefer to be employees for three reasons:

• We don't like any level of uncertainty in our lives and are willing to trade some percentage of salary for stability - human!
• We like being part of a team - human!
• We were never taught to be entreprenuerial - human perhaps, but a bigger failing in the education/mentoring picture

Wes has posted Part 2 before I get could this posted, so I'll wait on his Part 3 to finish my thoughts.

Microsoft BI Conference Oct 6-8, 2008

Had missed the announcement, came up in conversation yesterday with a friend, the BI conference will be Oct 6-8 in Seattle, registration is $995 if you register by Aug 8. Not planning to attend, so far I'm still firmly rooted on the conventional DBA side of things.

Notes on My Visit to Birmingham SQL Group

Spent last Tues/Wed in Birmingham, speaking at the user group Tuesday night and then presenting a seminar on Wed. Attendance at the user group was good, about 18, and had really nice participation as I did my standard presentation on transactional replication. They've only been back in business since about the first of the year and are showing good growth under the leadership of John Baldwin and with Barry Ralston & Robert Cain lending their support - especially with regards to finding speakers!

We spent some time Tues & Wed night talking about growing user groups and how SQLSaturday might work with that. Helped a lot that Barry has been to two (#1 and #4) and that Robert was in Orlando for #4 as well, so they have a better picture of how we try to do things and how we differ (slightly, but true) from Code Camps. They've got a lot of stuff to read through and discuss but I'm hopeful they'll be able to schedule one for sometime early next year (rushing is not a good idea).

They treated me well on my visit, including a visit to Dreamland BBQ, a local favorite, and mostly mentioned here because my friends Joe Healy and Wes Dumey love out of the way BBQ places.

Transparent, Translucent, or Opaque? Whats Your Strategy?

It's a couple weeks old, but there was a mild blog roar over some comments from Microsoft about wanting to be translucent rather than transparent. I think their reasoning is sound; no company should want or need to disclose the smallest detail about their business, their plans, internal arguments, or their minor failures. Is that imagement management? Sure. Spin control? Not necessarily, but sometimes. Evil? Certainly not!

I used to work for a teleservices company in the IT side, and we bid on a lot of projects - and didn't win them all of course. Would it have helped us - or our potential customers - if we posted every bid and the results? One could argue it might if we won all of them, but short of that, what would prospective customers take away from that list? That we were mildly successful? Hugely successful? Maybe easier to judge if we post the estimated dollar value of each contract? Or would they consider the company to be failing because it won only a small number of bids, not seeing that to win would have required losing money.

What about salaries? Would it help your customers if they knew what everyone made? Or would they be fighting to get the cheapest DBA on staff to work on their project, or arguing that the salary was out of line with local norms.

The blog post was about external communications. There's a different level of communication required for existing customers, for serious partners, and for employees. In all cases translucency is a valid strategy, and more useful than most believe at the team level. Why? Suppose you set up a team blog and update it once a week, putting in the 3 biggest things that happened that week. How often is one of those three going to be negative? One assumes that most teams don't have that many negatives, so each week you get 2 positive things to say, plus a negative that you can partially convert to positive by showing what happened, what went wrong, and what you're doing to fix it. Showing negatives is a great way to earn credibility, but showing positives is a great way to highlight - subtly - your teams achievements. We wouldn't want to announce every time someone came to work late, got a routine raise, injected a minor bug, etc, etc.

If the subject interests you try reading Transparency: How Leaders Create a Culture of Candor, or my article from last year on IT Transparency

SQLSaturday #4 Lessons Learned

Earlier in the week I posted a quick & positive note about the event, today I'll add some notes about things that could have gone better. Finding places for improvement doesn't detract all from the value delivered to attendees or the efforts of the volunteer speakers!

• We went with a smaller number of sessions at 75 minutes each to match the co-located Code Camp, trying to make it possible for attendees to cross events. In practice I saw very few cross over, and we would have been better off to have offered more sessions to increase the draw of the event.
• We had a larger than usual drop from the actual registration count. I attribute that to; having to pay $10 to park, no free lunch (and no simple way to get to lunch), it being held on a summer Saturday, and to having less content than at previous events (12 sessions vs usually 30-36). I think having lunch and more sessions the most important points.
• Just didn't quite generate the "buzz" we've come to love at these events. SQL rooms where not all located together, and the rest of the crowd was upstairs. Having a really large building actually works against us, there's value in putting people in a more constrained area.
• There were a lot of free books, but they were just put out to grab if you wanted. Lots of people didn't hear about the books until they were gone. Our technique of giving out book tickets is a simple way to alleviate that and exercise minimal control.
• Schedules and flyers weren't posted, leading to a lot of confusion the first two hours of the day.
• Coffee was only on the upper floor, out of the way for SQL attendees
• Not sure co-locating events is a huge win, it's mostly different audiences
• Logistics for the event was weird because the communities were only responsible for content, MS/Convention Center handled check in, flyers, etc. So we ended up not doing some of the things that make events run smooth - didn't leverage lessons learned.
• We had Sunday sessions planned that encouraged laptops, but we couldn't get a room with tables/power to the tables, had to run extension cords.

Link: Killing Terminal Service Connections

Needed to kill a connection so I get could logged on recently to a server and didn't have the server tools loaded, ran across this useful link on How to Kill Terminal Services Connection. Might come in handy for you some day. It's hosted on HacksZine.com, similar to the MakeZine.com site (the latter being very interesting, if only to find time to try all the ideas they come up with!)

Community Speakers/Leaders - Where's the ROI?

I participated in a lunch meeting recently with a number of people from MS that work on their community efforts, and I thought one of their questions was interesting, if obvious; what do you get out of participating in the community as a speaker or group leader?

I think it falls into three buckets:

• Indirect marketing, true for consultants and trainers
• Giving back/mentoring
• Recognition of skills earned

For me the first two apply. I do a one minute bio that includes what I do for a living and that's the extent of the sales pitch. Over time I hope to earn karma that comes back in the form of students in class. Just as important for me is that I enjoy helping those new to the profession grow, mainly because I see how much faster I could have grown if more help had been available/offered.

Nothing wrong the the last one, everyone reaches the point where they want validation - to prove to themselves, or their boss, that they are somebody. MS has accentuated this one - successfully I think - by making many of the community leaders MVP's. So part of this loops back to indirect marketing, hoping that listing speaker/community leader/MVP will lead to increased business (and I'm sure it does to some degree). The only downside to this one is that some point I think you should move past validation and move into the zone that only time/experience can bring - nothing left to prove.

I'm reasonably stubbon about my approach; I do the things I enjoy/want to do without worrying about the ROI. Not everyone can afford to do that, or would want to adopt such a karmic approach, but it suits me and seems to have worked so far.

Trigger Notes

One of the questions that came up during a panel discussion at SQLSaturday #4 was whether it was better to have one trigger or many. It's a Zen question, no real right answer as far as I'm concerned. In practice having 7 update triggers is probably not a good idea, both from a raw performance perspective as well as just being able to easily see what is going on. I like having separate triggers for insert, update, delete, though I sometimes combine them for basic auditing. I also like adding an additional trigger when I'm adding functionality that probalbly won't be permanent, when I'm done I can just drop the trigger with no danger I've made an incorrect edit to the existing trigger.

Another question was about auditing within triggers and making sure they get a true picture of the original state of the data. The deleted table holds the 'before' image of the data and that stays static for the life of the trigger. It doesn't matter if you read from it as the first line of the trigger or the last, it's still the before image.

The last question was about logging changes in column format, showing before/after value along with the column name. Totally valid and possibly lighter than my standard approach of just preserving a copy of the entire row. The only thing I'd argue for is a standard implementation so you don't get a mish mash that makes trying to use/report on the auditing data painful.

Notes on My Visit To The Space Coast Users Group

I visited the Space Coast group last night, hosted by Ken Tucker, and did about 90 minute of SQL Q&A with a nice group of developers who were all interested in data access (perhaps those not interested didn't attend!). We talked about partitioning, indexing, concurrency, blocking, deadlocks, stored procedure performance, and of course LINQ. They had good questions! Thanks to Ken and crew for inviting me to attend, and hats off to them for broadening their scope a little beyond .Net to address the needs of their members.

Also, Ken has secured a great facility for his group, a local bank has their headquarters in Melbourne no more than a mile from I-95, nice meeting room with tons of space, big whiteboards, and they provide a projector as well. Keep them happy so you can stay there!

SQLSaturday #6 in Cleveland - Registration Open

Long time acquaintance Allen White is hosting SQLSaturday #6 in Cleveland on August 9th. Registration and call for speakers is open, and once he gets back from Tech Ed will start to communicate with sponsors too. One note on the registration; if you're registering just to see what is going and don't plan to actually attend, be sure to set the status to say that on the reg form, helps us get a clearer view of the expected head count.

I'll be flying up to do a session and help out as I can on that Saturday, looking forward to meeting some new people and seeing how #6 goes!

If you're wondering about #5, you didn't miss it - Greg Larsen and crew are hard at work finalizing venue/date for #5 in Olympia WA sometime late Sep/early Oct this year. Registration is open, but no firm details yet.

Presentations using a Panel Format

At the recent SQLSaturday #4 we had a session end up finishing much earlier than expected, so we gave the attendees the option of moving to other sessions or staying for a Q&A session done with a panel up front. I've only done the panel format a couple times and by the time we finished realized we needed to learn a few lessons for next time. One is to decide if everyone should comment on each question. I think the ideal is whoever answers gives a complete/deep answer (to the extent it makes sense) and the others only join in if they have a contrary opinion. The complete answer is important, but hard to know - who can give the best answer out of the panel? We sort of went with let the most junior panel member try first, then work up from there, but I think it subtly makes the junior guy look junior - probably not fair. Perhaps another/better approach would be to make sure the panel members have similar skill levels.

I'd like to see a couple of these at each community event, there are a lot of questions waiting to be asked.

IndyTechFest Update

Just received this from my friend John Magnabosco about the SQL portion of the event: