OK, I know many of us have a short week this week because of the Labor Day holiday next Monday, so I want to get this post out early enough in the week so that folks can get started on writing. If you have the time, write your entry now and post it to go live next Monday or even on Tuesday. There really are no rules here other than me trying to give everyone a quick and easy writing assignment in an effort to help people keep their blogging juices flowing. And don’t wait to get tagged by anyone, just get writing!

Here is your assignment for the next Meme Monday: write about your favorite memory (or moment) from a previous PASS Summit. Here is mine, and it takes place in Dallas in 2005.

My company had an affinity (some might say fetish but I won’t because I’m classy like that) for using linked servers. See, data was everywhere, and everyone wanted an easy way to access the data. The developers would push for the creation of linked servers because, well, they could. And we did everything we could to make their coding challenges as minimal as possible. Part of that was coming up with a standard for how the linked servers would be named, as you would want to have consistent names in each environment (production, test, and development) in order to minimize the number of code versions that would need to be maintained.

At some point there arose a very simple question: is it better to have a minimal number of linked server connections used by many people, or to have many distinct linked server connections that would be used by only a few people each? In other words, do we name our linked servers with logical names that apply to the application usage, knowing we could have dozens of them? I didn’t know the answer. No one on my team knew the answer. No one in the company knew the answer. But I knew this: in two weeks I was going to be at the PASS Summit in Seattle. I told my manager that I would come back with an answer.

While there I was introduced to Bill Baker. I figured if anyone would know the answer (or know where to find the answer), it would be Bill. I asked him and he politely directed me to seek out Ken Henderson. Now, I didn’t know Ken, or anything about Ken at the time, all I knew was that Bill Baker pointed me to him, so I went. I found Ken in a session room, I think he was getting ready to give a session and was waiting for the current speaker to gather their things. I asked Ken my question and the next three to five seconds were a turning point in my database career.

Ken paused to think.

Ken didn’t call me an idiot, or dismiss my question as easily answered, or tell me that the way we were architecting something was wrong. He listened, then paused to think about the answer, and then gave me his thoughts. OK, maybe he was thinking I was an idiot, or possibly searching for the nearest exit, just in case. But he stayed and told me the number didn’t matter, what truly mattered was going to be the volume of activity. So, one linked server with a bunch of connections would have a certain amount of throughput expected, and that could equal a number of links using the same overall number of connections. He also talked briefly about memory fragmentation, saw my eyes roll into the back of my head, and we soon parted ways.

I had my answer, but I also had something much more. I was now a person that had good questions. Later on when I found out who Ken was it made me feel better about who I was as a database professional. After all, if the Guru himself didn’t know the answer right away, then it was OK for me to not know an answer right away, right? It was a milestone event for me as a database professional, and it happened so quickly.

And it happened at a PASS Summit.

I have two other stories about Ken that I like to share with folks. Find me at the Summit this year and I will happily tell you about them.