Navigating Yukon - A First Look

Navigating Yukon - A First Look

This series of articles will dive into the new features of Yukon, the release of SQL Server scheduled to succeed SQL Server 2000. I've searched around the web and I see bits and pieces of the product listed, but no real in depth look at them, so I decided to track my progress. As you read the articles, you may see changes in my experiences as the product evolves through Beta cycles and I learn more about it. I'll try to dig into particular features and do more than just mention them, though we'll learn together about the product. It's been a little while since I wrote this, but the NDA just lifted, so here's the first impression.

Setup

A brief look at the environment in which I'm working. The server is a Windows 2003 server, which I am somewhat unfamiliar with at this time (August 2003). Someone else set this up along with the Yukon Beta 1 on the system, so I'm "borrowing" it for my research. Here are a few specs:

Note that this will be the configuration for all articles unless otherwise noted.

Also I did not install the server or SQL, so I cannot comment on that process at this time. Since that will likely change, I'm not sure how big a deal it is. For now I'm concentrating on the actual features and things that I see.

First Impressions

I have to say that my first day wasn't all that exciting. Or impressed for that matter. I've been hearing bits and pieces about this product for nearly two years and I was expecting quite a bit. There were some basic demos at the SQL Pass Summit 2002, so I expected the June Beta to be fairly well along. What I found was that there are many features, and I mean many, at least from the GUI standpoint that are not implemented. Get used to seeing

quite a bit if you're working with this version. Now in fairness quite a bit of this seems to be with the client tools, which may be a fairly small part of the product. There is so much more to SQL Server than the client tools, but I'm an administrator and that's where I start. Suffice it to say that I was disappointed in my first day of "poking around" at the product.

SQL Workbench

I'm starting with the SQL Workbench because quite honestly that is where I expect most of us to start. We're not likely to install the server and fire up Query Analyzer and start coding. Most of us will startup the Workbench and see what we've got before we code anything.

What's SQL Workbench? It's the replacement for Enterprise Manager and Query Analyzer. Here's the shot I got when starting it:

You can see that this the interface is not based on MMC. Rather if you've used Visual Studio .NET then you'll recognize this as the development tool interface. I much prefer this as this is it seems much easier to use (in general), but it's a bit of a change and it seems like SQL is being positioned more as a development platform (which it is) than an administrative type server (like SMS).

In any case, at the top left you see a window which shows your SQL Servers. This is where you can create your groups, add new server registrations, etc. This threw me initially because I connected to the local server and then attempted to expand the view by double clicking the name.

And double clicking again.

I'm not completely dense, so I right clicked it:

That's when I realized there is nothing else here. The lack of an "Expand" option clued me in (old dog, new tricks, etc.). Then I noticed the Object Explorer window below and expanded that. Before I get to that, a few notes. First I could register older SQL 2000 servers, but since I didn't have network connections to any of them from this machine, that didn't work out as well as I would have liked. I'll get back to managing SQL 2000 servers from this interface later.

Second, I could register servers without connecting to them and having some crazy timeout period if I'd mistyped something. This was nice as I discovered I didn't have any servers nearby I could connect to (the lab is firewalled pretty tight).

Lastly, the Registered Servers window is "docked" in the development tool. If you're not a developer, this might be a new feature to you, but it is one that is very handy for rearranging your workspace, if you have multiple monitors, etc.Here's a look at a server group, another server, and the window "undocked"

One other item that seemed interesting is the Server Registration Properties screen. There are more options that are specific to the server and not global tool properties, which is nice. Especially if you have remote servers that might not respond as quickly. You can also include a description of the server in this list.

One interesting item is whether these registrations are easily portable and viewable by other users. If not, then the description might not be super handy, but it's another place to put (and lose) information. I did a search after registering the servers to see. I didn't find any files in a hard drive search and a poke around the registry was similarly uninformative, however, sometimes the obvious helps. I did a right click on the server in the "Registered Servers" window and saw an "Export" and an "Import" option. Selecting these brought me here, so I'm assuming I can easily port these registrations to other machines. I'll give that a test at a later time (like when I get another server).

Another thing that I like here. I can choose my authentication, nothing new, and save or not save the password, a great feature. However the item I like is the "Registered Server Name", which can be different from the server name (and instance). There are some times I'd like to name the registration differently (usually adding a word) than the server. This allows me to do this. I've sometimes used this to specify what the server is for, like when the server is "IBM304", I can register it as "IBM304-Dev Internet". The Connection Properties tab looks like this:

A bunch of nice features here. As I mentioned you can set different timeout values per connection here, but what I like is the "default database" feature. I've got servers that default my account to some database other than master. Why I don't know, but I know I can't change it without someone screaming, so I leave it. Man it would be nice to have my tools default to some other database on connection. Here you go.

Setting the network connection type separately for each server is probably something I wouldn't use very much, but it sure beats having to tab over to the Client Network Connection Utility and build some alias. This was an easy one and a long time in coming. Obviously the SQL Server team is listening to people's gripes and reacting to them (Thanks Euan!). More so from the grumblings I hear from other RDBMS vendors :). As I mentioned, the registration doesn't connect to the server when you click "Save". It's nice there is the "Test" option, but even nicer they don't force a connection.

Conclusions

That's it for now. As I dig further in, I'll be spending time on each feature that I look at, comparing it to SQL 2000, giving you my opinions on the product. I'd like to have feedback as well from people who've used the features I'm commenting on. Let me (and others) know what you think and if you've experienced something different or I'm misunderstanding or misrepresenting things. It's entirely possible because at this time Microsoft is limiting information about Yukon to a single site, of which I am not a part, so this is all "real world", user views of the product.

I'd also love to know what interests you. What features you want to hear more about. I am more than willing to have the readers map out my course through Yukon!

Be sure to check out the January issue of SQL Server Standard, the new magazine from SQL Server Central.com and PASS.

Steve Jones

©dkRanch.net August 2003

Return to Steve Jones Home