Ever seen this warning message while using the Management Studio?

All I did was open the AdventureWorks.Production.Product table in the designer, moved the ListPrice column above the StandardCost column and hit CTRL+S to save changes.  Instead of changing the table, it tells me:

Saving changes is not permitted.  The changes you have made require the following tabled to be dropped and re-created.  You have either made changes to a table that can’t be re-created or enabled the option Prevent saving changes that require the table to be re-created.

What a message huh?!  It needs to re-create the table, so what, go ahead!  Hang on, even though this is just a Warning, there’s no Continue button!  Ow come on, are you kidding?

Like any good developer that wants to get some work done, you stop reading such a long message after the second line and try to find a solution for your problem.  Too bad, you should have just continued reading the warning message because the solution is actually hidden in there!

If you open up the Options screen from the Tools menu in SSMS, and then drill down to the Designers > Table and Database Designers node, you’ll see an option called Prevent saving changes that require table re-creation.  And by default, that option is checked.  Remove the check from that box and you’ll be able to use the table designer as it was intended.

So, here’s your ADSOTD (Annoying Default Setting Of The Day)!

Small note: be careful when you want to use this feature on a large table.  The script that gets generated in the background to make the changes needs to copy all records from the old table into the new one and that will obviously require some time!

Have fun!

Valentino.

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.

That opens up the following familiar screen:

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.

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.

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

Be 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.

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:

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:

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

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

Have fun!

Valentino.

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

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!

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.

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