Tip : Keeping your DDL Trigger Audit Table in Check

Your naming scheme isn't important, but being consistent is crucial.

Tip : DDL Triggers to Track All Database Changes

Tip : Make your SQL Server database changes backward compatible when changing a relationship

Tip : Make your SQL Server database changes backward compatible when renaming an entity

I poke a little fun at the mind-numbing levels of profit these penny auction sites must be enjoying.

Gone are the days of the library or poring over a textbook. In the SQL Server community, your peers are your best learning resource.

Kept around for posterity; it's a bit comical in 2024 how much time and effort I spent trying to squeeze milliseconds out of splitting strings.

I've come full circle but in 2010 I sure had a lot of optimism for the common language runtime.

Tip : Make your SQL Server database changes backward compatible when dropping a column

See two BULK INSERT issues I came across and how I dealt with them.

Tip : Make your SQL Server database changes backward compatible when adding a new column

In this tip, I explain Unicode compression, the impact on space, and why it's beneficial.

I talk about a short list of things I'd love SQL Server to just get rid of already.

Tip : Simple process to track and log SQL Server stored procedure use

Tip : Find all columns of a specific data type using Policy-Based Management

I talk briefly about the toll the rest of your short-term responsibilities can take when you immerse your self in valuable training that will pay off in the long run.

I set out to disprove an argument that you can't possibly benefit from both data compression and backup compression.

I felt pretty strongly about some apparent bait & switch by SSWUG.

I talk about several things you can do to know and optimized what's going in and out of your disk.

I talk about creating a view that joins all the possible tables, and suggest that simplification isn't always worth it.

After getting tagged, I talked about a case where I tip-toed around a precarious and grumpy server for years.

See why it pays to be consistent about always aliasing every table and every column in your query.

This post explores what can happen if you are too liberal with permissions for the sake of convenience.

Let's talk about blindly clicking next, next, next during a SQL Server install.

IDENTITY columns are very useful, but consider whether they are needed on every single table.

I give two real-world examples of vulnerabilities allowing for SQL injection.

I talk about what I forgot to talk about at a recent presentation on Management Studio.

Decrypting an encrypted stored procedure is not difficult – but is it ethical?

I tried to deploy nested stored procedures that both had a cursor with the same name. It didn't go so well.

I explain how indexed views helped resolve a highly contentious e-mail delivery system.

I share my own experience with page compression in a production environment.

I talked about how much still gets onto your system when you try installing Visual Studio as minimally as possible.

Entity-attribute-value (EAV) is often frowned upon in the community, but there are some scenarios where it is on the right end of the trade-off spectrum.

Two quick and dirty procedures I deployed globally to make it easier to find modules containing a given string.

Find out about several bad things you may not even realize you're doing to dates and times in your own databases.

See why you shouldn't use alias types in SQL Server.

See why you should avoid some of the GUI elements in Management Studio.

Let's talk about a few of the ways people abuse and misuse DML triggers in SQL Server.

Read about some of the pitfalls of choosing the wrong data type in SQL Server.

In this post, I discuss some of the assumptions people make about IDENTITY columns.

One of many posts where I rant about how bad we are, collectively, at naming things.

I talk about how painful SELECT * can be, and how it can be like drinking from a fire hose.

See why your stored procedures should use OUTPUT and SELECT for data, and use RETURN only for error or status codes.

I talk about problems that can result from "problematic" characters in entity names.

Find out why you should always specify lengths for declarations of variable types like varchar.

A little wisdom on using sensible and logical aliases for your tables, instead of a / b / c / d.

See a couple of reasons you should stop using old join syntax (FROM t1, t2).