Data-Tales

Data Tales 5: The case of the rogue index

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

3rd party applications and indexes

Most of my end-user clients run applications that are written by other companies ie: 3rd party applications. Very few write most of their own applications. One of the endless challenges with this is that the application vendors never want their clients to make any changes to the databases that are used by their applications. As a customer, it can be very painful to see performance problems caused by poor or inappropriate indexing choices, and yet to be blocked out from fixing those issues by supportability concerns.

2025-09-19

Data Tales 4: The case of the phantom duplicates

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

As very few people seem to have worked with SQLCMD mode, I thought I’d start this article with a little background.

Some background

Way back in SQL Server 2005, Microsoft added SQLCMD as a new command line tool to replace OSQL. It was an OLE-DB based tool rather than an ODBC based tool and had a richer set of options. For example, you could execute operating system commands within your scripts.

2025-09-15

Data Tales 3: The case of the stubborn log file

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

Anyone who has worked with SQL Server for any length of time knows the common errors that happen. Before a new user even completes their question, you often know how it’s going to end.

One of those questions is always about database log files that keep growing and growing until they fill all available disk space. Sound familiar? We’ve all heard about that one and most of us would have a straightforward checklist for what to look for.

2025-09-07

Data Tales 2: The case of the exploding table

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

I was recently at a customer site where the developers were very concerned about the impact of adding columns to a table. They told me that when they added a new column that their deployment code was timing out and the database was massively increasing in size.

The table had increased from around a small size to well over 50GB during the single operation. The deployment operation involved adding the column and writing one row to a deployment history table. Because they were only writing a single new row, they were blaming SQL Server for bloating the database size when a column was added.

2025-09-03

Data Tales 1: The case of the auto-truncating data

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

I have a number of clients that I spend a day or two with each month. I like this style of engagement as I get to know the staff and their systems over a period of time, can see the improvements that we make over time. The staff members also know that if they have issues that aren’t desperate, they can save them up for the days that I am onsite. When I arrived at one of these customer sites recently, several of the staff members had grins on their faces, and one told me that Terry (well let’s call him Terry anyway) had really broken something.

2025-08-30