DataTamer: SQL Server Services

Onsite in Vancouver

February 25, 2011 · No Comments

I flew into Vancouver very late last night and took the Canada Line into downtown.  My hotel was about a ten minute walk from the station and I had no problems getting all settled in for the evening.  This morning has been a lot of last-minute email and details.  Once the team is assembled, we'll be putting the attendee bags together and reviewing the attendee name tags and raffle tickets for any late payments.

The view is incredible, and this little picture doesn't do it justice.  I'll have to take more Sunday when I have some time to take a walk on the boardwalk.

Vancouver View

Categories: SQLSaturday

Venue locked in

January 06, 2011 · No Comments

It certainly took a lot of negotiating, but we have secured the venue.  Blythe has locked in a nearby hotel for a great nightly rate since the main venue couldn't get prices below $195 a night.  That's just way too high for a bunch of volunteer speakers that are travelling internationally for this SQLSaturday.

What would I do differently?  Start sooner with the venue, negotiate hard, and lock it in before doing a lot of advertising.  We have some time pressures in order to take advantage of the MVP event in Seattle so we've had to push hard and fast to get this together.

Categories: SQLSaturday

Venue negotiations for SQL Saturday

November 28, 2010 · No Comments

Plans for SQL Saturday Vancouver are moving forward.  Scott has taken on the speaker list and is coordinating track leads, Richard is heading up the volunteers and I've taken on the venue and sponsorship.  At the moment we are having some difficulties getting our costs down.  Hosting an event at a hotel means you are at the mercy of their registration desk.  A hotel uses the meeting rooms to fill the sleeping rooms, not the other way around.  Since our attendees will be local the hotel is going to try to make all of its profit on our catering fees.  We need to bring these costs way down in order to be successful.

Categories: SQLSaturday

List all columns

November 16, 2010 · No Comments

This is a handy bit of code to list all columns in a given table:

SELECT * FROM sys.columns WHERE [object_id] = object_id(N'[dbo].[ibProject]',N'U') ORDER BY [column_id]

Categories: Snippets

A review of the initial steps for SQL Saturday

November 15, 2010 · 1 Comment

My initial steps actually started early in the year.  I found myself with a large non-refundable deposit on a hotel conference room and no-one had brought SQL Saturday to Canada yet.  Due to some miscommunication with the hotel I had put the entire thing on hold for a while.  An unexpected email indicated that my deposit was still valid but I needed to reserve dates by the end of the year.  So that got things rolling again.

The first thing I did following this email was to contact the PASS SQL Saturday coordinators.  This initial contact put me in touch with Scott Stauffer of Scott was interested in bringing SQL Saturday to Canada as well (specifically Victoria and Vancouver). We discussed some initial concepts and plans.  I then filled in the official SQL Saturday request form.

A conference call was arranged between PASS and Scott and me. We needed to discuss our plans, go over a few common "gotchas", and review the process.  Nancy is our PASS contact and she has been wonderful throughout our interactions.

Next I needed to return the SQL Saturday contract.  Nancy and Sanjeet set up our SQL Saturday website and provided our official number: 65.

Categories: SQLSaturday

SQL Saturday in Vancouver!

November 03, 2010 · No Comments

We have an official SQL Saturday ready for Vancouver: #65 on February 26!  I'll be blogging about the process of creating a SQL Saturday from the initial contact with PASS right through to follow up with the attendees.

Categories: SQLSaturday

Wherefore art thou, nocount?

October 31, 2010 · No Comments

Some days I code faster than I think.  As a practice, I always set nocount to on within a stored procedure to reduce the data being returned from a function call.  I admit that this data is minimal and may not be worth worrying about on smaller systems but I believe in consistency and allowances for growth.

In my development database I wrote a new stored procedure to provide a quick data update on a parent / child type of table set.  This procedure updates child records based on a parent ID as well as a child record seniority.  I tested the procedure by running it and pulling the child records for my given parent ID.  However, I had missed a portion of the where clause.

Do you see the flaw?  I had actually updated the entire child record table but only reviewed the data for a single parent ID.  Setting nocount to on masked this flaw and I didn't catch it until a code review later in the day.

To sum up: using nocount is one of many methods to reduce your data stream, but make sure you turn it off during development and testing.