Sort of.
I’m off for a week to Camp Alexander near Pikes Peak for Boy Scout summer camp. My 13year old is attending and working his way toward Eagle Scout. He’s a Star scout now, and with any luck, this week we’ll get 3 more of the Eagle required merit badges and be that much closer to that amazing achievement.
There’s no cell service, and no real Internet, so I’ll be completely out of touch for a week.
Everyone behave.
I read Eddie Wuerch’s post on cross-submissions for SQL Saturdays and found it hitting close to home. It provoked a few thoughts, and I wanted to write a little bit about what I think since it’s something I think more and more people will deal with over time.
The idea behind SQL Saturday was to get more local events, more local speakers, and improve our industry at a grass roots level. That was Andy Warren’s vision, and it was something we strived for as we grew the SQL Saturday framework. Over time it’s evolved into something we never expected, with many speakers traveling from remote locations to talk.
It’s also grown so much that many of the weekends of the year have multiple events. This year we have 58 events (completed or scheduled) and we have multiple collisions, including
There are also plenty of weekends with two events.
As a speaker, I like attending these events. I’ve been to quite a few, and I turn many more down because of scheduling conflicts. I try to get to 4-5 a year, and meet a lot of people. These are fun events, and I’d like to do more, but travel is hard and it takes away from other things in my life.
When I decide to submit to a SQL Saturday, I usually start making plans to attend. I don’t book travel, but I free up my schedule, and I don’t submit to events on consecutive weeks. Traveling two weeks in a row, while it might not seem like much, is a big impact to my family, and to me.
My method for dealing with multiple events and choices is to contact the organizers of my first choice. I don’t ask them for a favor, but I do ask if they would like me to submit and attend. I’ll give him an idea of what I am prepared to talk about and let them know that I don’t want to submit if I’m not being chosen, only because I would like to attend some event that weekend. If they decline, and I have had some decline, I thank them and contact my second choice.
I don’t like the idea of adding in more rules, or restrictions, or even asking the organizers to work out among the various events who will get speaker X. I think it’s the burden on the speakers to make as little an impact on the organizer’s workload.
Uploaded here if you need them. These are the PPT deck and the code.
It’s T-SQL Tuesday time again, and this month Aaron Nelson (blog | @sqlvariant) is hosting. The topic is logging, and if you’re like to participate, read Aaron’s post and learn the rules. We do this on the second Tuesday of every month.
If you’d like to host, contact Adam Machanic. It’s easy to do. Get on the schedule, pick a topic, and then write a post.
A list of previous posts is here,
I’ve found documentation of events to be one of the most important things I can do in my career. Finding out what happened, what changed, or what I did has been important many times, and often helped me come through difficult situations.
Logging is the automated version of documentation. All kinds of applications, including SQL Server, produce logs of the various activity on the system. In SQL Server, we are moving to an eventing system, and if you haven’t looked at Extended Events, you should.
One of the times when I found logging to be lacking was in a startup I worked at a decade ago. We had a number of developers that were working on various development servers. They had full rights, and they were allowed to build their own objects. That was a little concern to a controlling DBA like me, but I allowed it since they often wanted new objects quickly, and if I allowed them to write their own, they’d use stored procedures.
A good compromise, if you ask me.
However in the hectic pace of development, I found that the developers didn’t often keep good notes about what was being built for which features and functions. Since we had to produce a build script fairly quickly every Monday in order to update our QA systems, we would find that developers invariably would forget objects and we would not have a well tested QA script on Monday afternoon.
I decided that we needed to better log the changes on our development server. I didn’t care about every change, especially intermediate changes to objects, but I did care about the gross changes made each day.
This was in the SQL Server 2000 days, with limited tracking of changes outside of SQL Trace. Since I had no desire to move through lots of trace files, even in an automated fashion, I decided on a much simpler method.
In sysobjects (now sys.objects), there was a crdate field, which tells you when the object was created. However that doesn’t change if an ALTER TABLE is run (or any other ALTER). That stumped me briefly, but I decided to search further.
I found that there was a schema_ver field, which is incremented every time the object is changed. Since the majority of our developer changes were ALTERs, I could track the version number and then compare this each day. I tested this out, and it worked well.
The outline of the solution is that I grabbed a copy of the sysobjects table every day and stored it in a temporary table. I then used a left join to compare this with the previous values stored in a table I’d created to store the data. When I found differences, I logged them in a table, along with the date, and sent myself an email. I would then overwrite the stored version of the objects with the version from the temp table, giving me a baseline for the next execution.
At the end of the week, I’d have an aggregate list of all objects changed, which I could then compare against our build script.
At the time we were in an agile environment, releasing new code every Wednesday, and operating on very short timelines. The logging I did cut down on mistakes and allowed us to have a smooth release process that functioned for over 18 months, with code releases nearly every Wednesday outside of holidays.
