When you define a foreign key in SQL Server, you can choose what happens to the child rows when the parent row is deleted or updated. One option is SET DEFAULT. With this setting, SQL Server updates the foreign key column in the child table to its default value whenever the parent key is deleted or updated.
It’s not the most common option, but it can be useful if you want to preserve child records while moving them to a “default” category, user, or state.
One of the neat features in SQL Server is the ability to set up cascading deletes on foreign keys. Instead of writing a bunch of manual DELETE statements to keep related tables in sync, you can let the database handle it for you. This is especially useful when you’re working with parent-child relationships, where deleting a parent should also remove all of its children automatically.
When working with data, we often need to roll up numbers by categories. For example, calculating sales totals by region, or averaging test scores by class. SQL Server’s SUM() and AVG() functions can work perfectly for this scenario when combined with the GROUP BY clause. This combo can provide quick insights without having to do the math yourself. Let’s walk through how this works with an example.
The MAX() function is one of SQL Server’s simplest aggregate functions. It returns the largest value from a column. While it’s usually straightforward, there are a few useful ways to apply it depending on whether you’re using it as a plain aggregate or as a window function with OVER().
You might also see MAX() that use a DISTINCT clause. Truth be told, this doesn’t actually change the results. That clause is only for standards compatibility.
In any case, let’s walk through some examples to see how it all works.
Common Table Expressions (CTEs) are a handy way to break down a complex query into readable, reusable pieces. When you need several intermediate results – say, a filtered set, an aggregation, and a ranking – you can stack multiple CTE definitions together. PostgreSQL, SQL Server, MySQL 8+, and many other engines support this syntax.
SQL Server 2022 introduced the DATETRUNC() function, which makes working with date and time values much easier. It trims (or “truncates”) a date/time value down to a specified part (like year, month, or week) while setting all smaller units to their starting value. This helps avoid the common hack of mixing DATEADD() and DATEDIFF() just to snap a timestamp to the beginning of a period.
In this article we’ll look at some examples that demonstrate how it works.
When working with SQL Server, you may often find yourself having to shift a date by a certain number of days or months. While it sounds simple, the right function and approach can save you from subtle bugs and errors, especially when dealing with edge cases like leap years or month-end rollovers.
Let’s take a look at how to add days and months to dates in SQL Server.
Importing data into SQL Server is usually quite straightforward. That is, until you run into date and time formatting issues. Dates that look fine in a CSV, Excel, or flat file can suddenly throw errors or, worse, silently load with the wrong values. Since SQL Server is strict about how it interprets dates, mismatches between source file formats and SQL Server’s expectations are one of the most common headaches during imports.
This article looks at why these errors happen, what SQL Server expects, and how to troubleshoot these pesky date format issues.
If you’ve worked with SQL Server long enough, you’ve probably run into the dreaded “Only one expression can be specified in the select list when the subquery is not introduced with EXISTS” error. This error usually pops up when you try to use a subquery in a place where SQL Server expects a single value, but your query is returning multiple columns or multiple rows.
It’s a simple mistake, but it can be frustrating until you understand why it happens and how to fix it.
One of the most common causes of errors in SQL Server is trying to insert the wrong type of data into a column. If a column expects an integer but you push in a string, SQL Server will either throw an error or attempt an implicit conversion that may not work the way you expect. This is more common when data comes from external sources like APIs, flat files, or user inputs, where you don’t always control the formatting. Validating data types before inserting not only prevents runtime issues but also keeps your tables clean and predictable.