MSITAC and Little Things

Attack of the Acronyms! Run for your life!

Actually, I somehow manage to snag (via third party source, which I will not divulge) and invitation to participate on the Microsoft Information Technology Advisory Council. It's basically a big old focus group for geeks. You get a private blog, forum and other stuff so you can share info about the technological direction that MS is going.

So far, it seems cool, although it took me a while to get the ability to post to my Council blog, and when I wrote up a post, I saved it instead of posting it. Now I can't seem to post it. Weird. I'm sure I'll get it figured out. Some geek, eh?

The first post I wrote was about SLA's, Service Level Agreements, to the uninitiated. Basically, it's a written contract between you and your department, and your employer. You agree on how the operation should run, what kind of performance is expected, and what the procedures and turnaround times would be for any issues that might arise. An example would be an agreement that states that should a database be damaged, it will be restored to operational status within 1 hour, and will lose no more than 10 minutes worth of data. Based on that, you formulate your backup and recovery plan. That's the post I can't get to at the moment.

The second post I plan on writing, which I will echo here, is an experience story and a question to all who may read that blog. Or read this one, for that matter. How much do the little things matter, and at what point are the little things not so little?

When SQL Server 2005 came out, I was excited about it. I had gotten a copy of the Express edition and had started playing with it a bit. The management environment was very new to me, and I had fun exploring it. I had picked up on a couple of conversations on message boards, about how poorly the new interface worked. I did get to a point where it worked poorly for me as well, and where it seemed clunky, and I echoed the same sentiments. After a time, I got used to it, and learned a few new ways of working with it. Now, I am enjoying it again.

Not that the interface is without it's problems, and here's where I get to the point. There are one or two... little things that irk me. Little quirks in the interface that just don't make sense. For example, when creating a server connection in the query window, you have 4 fields in the basic dialog. There is server name, authentication type, user name, and password. For most local servers, we use Windows Authentication, but for the remote boxes which are not on the domain, we use SQL Server Authentication, which requires you to enter the user name and password. When you tab through these fields the first time, the cursor behaves as expected. You type in the server name, hit tab, then type 'S' for SQL Server Authentication, hit tab, type in the user name, hit tab, then type password. Simple.

Now, suppose you type something incorrectly, say, the Server Name. No problem. Hit tab. The Server Name is now highlighted and can just be typed over. So you do that. Now let's say the user name is wrong. Hit tab a couple of times, and the user name field is highlighted, and can be typed over. Oops. You typed in a different user name, and you forgot to change the password. Ok, so you hit tab a couple of times and type over the password.

Except, you dont. The password field does not highlight when using the tab key. Instead, it moves your cursor to the end of the password as if to append to it. It is the only field in the dialog that behaves that way. My question is why? It's certainly not a security concern, as far as I can see, and if you're used to the normal way that the text fields work, it's inconsistent and causes login failures. Personally I find it annoying.

Another little bug (ok, maybe not a 'bug') is in the SSIS Exec utility, in that it only works on the local server. By this, I mean that if you run the SSIS Exec utility on your local machine, the package must be on your local machine in order to work. This, despite the fact that there is a selection box for "Server" where you can designate any server you can connect to. Why make a utility that can connect to any server, yet only runs local packages? Note that this little gotcha is manifested in an error message that declares there is a 'version mismatch' and that you should upgrade your version of the SSIS Exec utility. Hardly accurate, or descriptive to the issue.

These are two relatively minor issues, in my opinion, and SQL 2005 is a pretty good product after all. The question I put to the reader is, how minor is minor? Should I contact MS and make a fuss about this? Or, should I accept the state of things and just work around it for now?

Thoughts?

-D.

P.S.: If anyone reading this is not already on the advisory council and would like to be, email me and I'll get you an invite.