Management Studio

You are currently browsing the archive for the Management Studio category.

One is never too old to learn, right?  Here’s a Management Studio feature which has been introduced in SQL Server 2008.  And I’ve discovered it about a month ago.  Since then, I use it every day!

What am I talking about?  Well, the Management Studio allows you to link a color to a connection.  Each time when you open a window, the color of the status bar will change to the one linked to the connection to which your window is connected.  Still with me?  Alright, I’ll get the drawing board out.

To link a color to a connection, open up the Connect dropdown in the Object Explorer and choose Database Engine.

Object Explorer: Connect to Database Engine

That opens up the following familiar screen:

Connect to Server window

Do you see the Options button indicated with the red arrow?  Click it to open up additional options that you can set on your connection.

Connection Properties: Use custom color

To link a color to the connection specified in the Login page, activate the Use custom color checkbox and select a color.

Now click the Connect button and open up a new query window.  My favorite way of doing that is to open up the Databases tree node in the Object Explorer, select the database in which I’m interested, and hit CTRL+N.

With the new window open, did you notice the status bar?

Here you can see the status bars from two different query windows connected to two different instances on the same machine.

Purple status bar connected to SQL Server 2008 R2

Green status bar connected to SQL Server 2008

The way I use these colors is as follows:

  • Green for the servers in the Development environment
  • Orange for the servers in the Acceptance environment
  • Red for the servers in the Production environment

This gives you an extra safeguard to ensure that you’re executing that TRUNCATE TABLE statement on the right server.

However, as usual there are some things to take into consideration.

Things To Keep In Mind

localhost is not the same as <YOUR_MACHINE_NAME>

Be careful when you’re connecting to SQL Server instances on the local machine.  As the title above indicates: “localhost” and “BigBlue” are not the same (assuming that your PC is called BigBlue).  If you want to avoid trouble, set up the same color for both connections from the beginning.

Registered Servers

If you’ve got a habit of using the Registered Servers window, it’s important to know that the color specified here is completely separated from the color specified on the same connection through the Connect to Server window.

In fact, I believe all connection settings are set up separately when using this tool.

Change Connection On Open Window

Change Connection buttonBe careful when you use the Change Connection button on an open window: it messes up the coloring.  More precisely, it will keep the color of the previous connection.

There’s a bug filed on Microsoft Connect related to this, current status is Won’t Fix.  Which seems a bit weird: I noticed different behavior on SQL Server 2008 R2.  When changing my connection from SQL Server 2008 to R2, it would update the color to the one linked to R2.  In the other direction, disconnecting from R2 and connecting to SQL 2008, it would not change the color.

Update: I’ve found a couple additional bug reports on Connect related to this feature. If you’d like to see some consistent coloring behavior (and avoid the risk of executing a TRUNCATE TABLE on the wrong server), please take a moment to vote Yes at the following pages.

Connect: Update status bar colour when changing connections

Connect: [SSMS] Make color coding of query windows work all the time

Conclusion

Currently, to get consistent coloring all the time, you need to set up the colour three times for each connection: once in the Connect to Server window, secondly in the Connect to Database Engine window (this is the window that you get when clicking the Change Connection button), and thirdly in the Registered Servers pane (if you’re using this pane).

That’s it for now, have fun coloring those status bars!

Valentino.

  • Share/Bookmark

Tags: , , ,

Using the Management Studio (SSMS) I just received an error which I hadn’t seen before.  Here’s what I was doing.

On my freshly-installed Windows 7 64-bit machine I have both SQL Server 2008 SP1 and SQL Server 2008 R2 (NOV CTP) running (both 64-bit as well).  And I just installed the new Contoso data warehouse and OLAP DB.

After setting up the data source connection of the Contoso_Retail OLAP database and processing it successfully, the next logical step is to try and browse the cubes, through the Management Studio.  So that’s what I tried, but unfortunately it gave me the following error:

Invalid class string (Exception from HRESULT: 0x800401F3 (CO_E_CLASSSTRING)

Hmm, okay, that doesn’t look good!  “Invalid class string”, what does that mean??

So I tried the link that says “Click here to see detailed error information”, which gave me this:

Error pop-up: I don't see the details

I’m sorry, but where exactly are the details in this message?

Luckily a quick internet search gave me the solution (and reminded me of something which I actually knew but just didn’t think of because it’s all running in a totally new environment).

To browse cubes, SSMS is using a component from the “Microsoft Office 2003 Web Components” package, whatever that that means.

And the solution (as described here) is to:

  • Open the list of installed programs (Windows Key + R > appwiz.cpl > enter)
  • Locate the Office 2003 Web Components, right-click and select Change
  • Follow the wizard to repair/reinstall the components

Programs and Features

And now I am able to browse the cube without any issue!

Have fun!

Valentino.

  • Share/Bookmark

Tags: ,

Ever since I upgraded to SQL Server 2008 Service Pack 1 I noticed that the Management Studio was reporting incorrect version numbers when connected to Integration or Reporting Services.  This incorrect version number is located to the right of the server instance in the Object Explorer.

As usual, a picture says so much more than … :

Object Explorer showing wrong version numbers

As I have posted earlier, 10.0.2531 is the version number for SP1, while 10.0.1600 is the original RTM version number.

I never really spent time looking for an answer to this.  It was obviously a bug but I could live with it and someone else would probably already have filed it as being a bug.  So recently I came across a post by Phil Brammer that mentioned this issue.  This post got a comment from Matt Masson, a developer on the SSIS team.  Have a look at the comment but in short: the version numbers that are being shown in the Object Explorer are actually the version numbers of the service’s .exe file!  And SSMS is now showing the wrong number because these files didn’t get an update in SP1.

After a little search I found the bug report on Microsoft Connect, reported on March 11, 2009, by Dan English.  Its status is Fixed but it seems that it isn’t.  At least, looking at the comments, CU5 (Cumulative Update) for SQL Server 2008 SP1 is still showing the problem.  So I guess you could go over to the Connect page and click on that Yes button if you’re interested in seeing this fixed.  After all, it could be quite misleading to novice DB guys and gals…

On this same subject, there’s another interesting post by Adam W. Saxton, a member of the Microsoft SQL Server Escalation Services Team.  In this post he takes a closer look at the SQL Server 2008 Reporting Services version number after having installed CU2.

Conclusion: if you need to find out what version your server is running, do not rely on the version numbers that you see in the Object Explorer.  As Adam explained, one way is to look at the version numbers of the files that were included in the upgrade.  But that may a bit of an overkill.  My favorite way, assuming that all components of the SQL Server installation have been upgraded to the same version, is to use the following query:

SELECT @@VERSION;

 

On my machine that comes back with the following result:

Microsoft SQL Server 2008 (SP1) – 10.0.2531.0 (Intel X86)   Mar 29 2009 10:27:29   Copyright (c) 1988-2008 Microsoft Corporation  Developer Edition on Windows NT 5.1 <X86> (Build 2600: Service Pack 3)

And remember, have fun!

  • Share/Bookmark

Tags: , , , , , , , ,

Having trouble connecting to your 2005 Integration Services using Management Studio 2008?  Even when you only have SQL Server Integration Services running, and not version 10.0?

Integration Services

To make it even better, have you noticed that SQL Server Integration Services 10.0 will start up when you connect to it from SSMS 2008?

Well, that’s by design.  SSMS 2008 can only connect to SSIS 2008.  And SSMS 2005 can only connect to SSIS 2005.  So don’t go uninstalling the 2005 Management Studio to save some space if you use Integration Services 2005!

There’s some (limited) info on Microsoft Connect and on SQL Server Central.

Update: when trying to use SSMS 2008 to connect to SSRS 2005, an error coming from the Report Server WMI provider will show up complaining about a couple of invalid namespaces (Microsoft.SqlServer.Management.UI.RSClient and System.Management).  It has been reported as a bug on Microsoft Connect.  Microsoft’s feedback is that the issue is caused by a breaking change in the WMI namespace and that it won’t be fixed.

So there you go, neither Reporting Services nor Integration Services 2005 can be connected to using Management Studio 2008.

  • Share/Bookmark

Tags: , , , , , , , , ,

Have you ever had the situation that you wrote an MDX query to get some data out of a cube in Management Studio and executed it and waited and waited and the query never seems to end so you decide to cancel it so you click the red square button and then you wait and wait and wait some more and….  Well, it’s a bug.

And the worst part of it, in my opinion, is that, even when you close your client connection to Analysis Services, the query keeps running on the server consuming CPU and memory and will finally take it down.

The good part is that Microsoft has fixed it in Cumulative Update 2 for Service Pack 2 for SQL Server 2005.  And now of course SP3 can be used as well to fix this situation.

The bug is described here: http://support.microsoft.com/kb/935832

  • Share/Bookmark

Tags: , , , , , , , ,

© 2008-2010 A Developer's Blog All Rights Reserved