Azure-Sql-Db

SSMS Tips and Tricks 7-11: Providing feedback directly to the SSMS team

In the current version of SSMS, there is an option to provide feedback directly to the SSMS team. While you can just browse to the website, you can click this link in the top right-hand side.

At that point, you are given three options:

The first two end up in very similar locations, just with a different preselected context:

Make sure you search first to see if the problem has already been reported. As soon as you provide a title for your issue, the site does a search and shows you issues that are potentially related. If you see the same issue, you can click on it to go to the discussion and add your own comments there.   If the issue hasn’t already been reported, you can create a new issue. Make sure you provide a clear title, then detailed information about how to reproduce the issue. Finally, before submitting, make sure you indicate the impact you are experiencing:

2025-10-18

SSMS Tips and Tricks 7-10: Setting startup options

When you start SSMS, the default action at startup is to open Object Explorer. But you can change that behavior. The options to do that are in Tools. Options, then Environment, and Startup.

These are the options that are provided:

One that is often surprisingly useful is to open an empty environment. You might want to use SSMS to edit files without any connection to a database and not want to waste time waiting for SSMS to open the connection dialog, just for you to close it again.

2025-10-16

SSMS Tips and Tricks 5-9: Closing idle connections

One challenge that I find with T-SQL is that there’s no 100% reliable way to drop a database.

I wish I was joking.

If you execute DROP DATABASE, the command will fail if anyone is connected to the database. The way that we normally drop databases is as follows:

USE master;
GO  

IF EXISTS (SELECT 1 FROM sys.databases AS d WHERE d.[name] = N'somedb')
BEGIN
    ALTER DATABASE somedb SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
    DROP DATABASE somedb;
END;

That mostly works, but the problem is that I need to execute the command from the master database. That means that when I set the database to single user, I don’t know that I’m the single user. What I’ve seen happen sometimes, is that the Intellisense system in SSMS is reading further down my script, where I’m perhaps recreating the database, and it’s maintaining a connection to the DB.

2025-10-14

Data Tales 11: The case of the ballooning tables

This is the eleventh tale in a series of stories about data. I hope you enjoy the series.

Recently, I’ve written a series of articles on how the overall size of a financial services database was tamed by the application of table compression, XML compression, and PDF size reduction. I have applied this approach at many sites but recently came across one where the outcome seemed to constantly be getting worse rather than better. Every time I tried to improve the situation, it got worse. Let’s discuss why.

2025-10-13

SSMS Tips and Tricks 8-6: Using the PowerShell terminal

SSMS used to have a built-in web browser. That’s now gone.

What was added, though, is a Developer PowerShell window. On the View menu, you can choose Terminal.

This will then open a Developer PowerShell window:

Note that you can change the version of PowerShell that’s launched, from the drop-down. But the Settings option will take you to the Tools Options page where the Terminal can be configured.

2025-10-12

SSMS Tips and Tricks 8-5: Undock tabs and windows and using multiple screens

Like Visual Studio that it’s based upon, SSMS is very flexible when working with query windows and tabs.

Most people realize that you can undock and move tabs and windows around. Usually they discover that by accident and then realize that the Reset Window Layout option in the Window menu is helpful.

But one option I’ve found that many people don’t seem to realize is that you can undock just a single query window and move it outside the bounds of SSMS. You can even place it across on another screen if you have multiple screens.

2025-10-10

Data Tales 10: It's a matter of existence

This is the tenth tale in a series of stories about data. I hope you enjoy the series.

I regularly see code that calculates a count of a set of rows then makes a decision that’s based on the count, but only on whether or not the count is zero. Consider this (slightly contrived) example based on AdventureWorks:

DECLARE @PersonCount int;

SELECT @PersonCount = COUNT(*)
FROM Person.Password
WHERE BusinessEntityID = 12
AND PasswordHash = 0x208394209302;

IF @PersonCount > 0
BEGIN
    PRINT N'Password matches';
END;

Now I’ll start by saying that the last thing I’d ever want to see in SQL Server code is this sort of playing around with users and passwords, but I’m ignoring that for now.

2025-10-09

SSMS Tips and Tricks 8-4: Using document groups

In a previous post, I showed how you might use split windows to allow you to work on different parts of a single query at the same time.

But what if you need to work on two queries and see parts of both of them?

That’s where document groups can help you. You can create both vertical and horizontal groups. For me, the most useful is typically side-by-side vertically, for when I’m comparing two sections of code.

2025-10-08

SQL Interview: 84 Nested views

This is a post in the SQL Interview series. These aren’t trick or gotcha questions, they’re just questions designed to scope out a candidate’s knowledge around SQL Server and Azure SQL Database.

Section: Development Level: Medium

Question:

You are reviewing your development standards and notice that there is a warning about making sure you don’t nest views.

Why would this be an issue?

Answer:

Nested views hide complexity, and worse, the SQL Server optimizer might not be able to eliminate all the tables from the query that it could otherwise have done. This can lead to serious performance issues that could have been avoided.

2025-10-07

Data Tales 9: The case of the database diet (Part 4) - the final cut

This is the ninth tale in a series of stories about data. I hope you enjoy the series.

In the first article we saw why size really does matter, both for the DB itself and all the other copies of it that exist in most organizations. We then saw how to estimate the improvement in size with ROW compression. Our customer’s database that started at 3.8TB was reduced to 2.6TB by applying ROW compression without any code changes. Better still the performance of the I/O bound application improved significantly by compressing the tables and indexes.

2025-10-05