This is the classic reason to convert rows into columns in SQL. The database holds narrow, tall data, and reports want wide, flat data. SQL Server gives you three solid ways to do it: the PIVOT operator, conditional aggregation with CASE, and dynamic SQL when the columns are not known in advance. This guide builds each one, explains the trade-offs, and covers NULLs, performance, and secure reporting in SQL Server and Azure SQL Database.

What “Rows Into Columns” Means

Turning rows into columns is called pivoting. You take the distinct values from one column, such as Q1, Q2, Q3, and Q4, and turn each into its own column heading. At the same time, you aggregate, which means combine many rows into one value with a function like SUM, so each cell of the new grid holds a single number.

Every pivot has three parts:

• Row identifier: the column that stays as rows, such as Product.
• Pivot column: the column whose values become headings, such as Quarter.
• Value column: the data that fills the cells, such as Revenue, with an aggregate.

The opposite operation, turning columns back into rows, is called unpivoting; see SQL UNPIVOT.

Pro Tip: In my experience, I write down those three parts on paper before touching the keyboard. Nearly every broken pivot I have debugged was missing a clear answer to “which column becomes the headings?”

Create a Practice Table

A schema is the structure of your tables. Use a small sales table with realistic gaps and a duplicate.

CREATE TABLE dbo.QuarterlySales (
    SaleID   INT IDENTITY(1,1) PRIMARY KEY,
    Product  VARCHAR(30)   NOT NULL,
    Quarter  CHAR(2)       NOT NULL,
    Revenue  DECIMAL(10,2) NOT NULL
);

INSERT INTO dbo.QuarterlySales (Product, Quarter, Revenue)
VALUES
 ('Laptop',  'Q1', 100.00), ('Laptop',  'Q1',  20.00),
 ('Laptop',  'Q2', 120.00), ('Laptop',  'Q3',  90.00), ('Laptop', 'Q4', 150.00),
 ('Monitor', 'Q1',  60.00), ('Monitor', 'Q3',  70.00), ('Monitor', 'Q4',  80.00),
 ('Dock',    'Q2',  30.00), ('Dock',    'Q3',  40.00);

After executing the above query, I got the expected output as shown in the screenshot below.

Run this only in a test database, because it inserts rows. Notice three deliberate details. Laptop has two Q1 rows that must be added together. Monitor has no Q2 row. Dock has no Q1 or Q4 rows. The expected wide result is:

How to Convert Rows Into Columns in SQL With PIVOT

The PIVOT operator is built into T-SQL for this job. It works in SQL Server and Azure SQL Database.

SELECT Product, [Q1], [Q2], [Q3], [Q4]
FROM (
    SELECT Product, Quarter, Revenue
    FROM dbo.QuarterlySales
) AS src
PIVOT (
    SUM(Revenue)
    FOR Quarter IN ([Q1], [Q2], [Q3], [Q4])
) AS p
ORDER BY Product;

Here is what each piece does:

• The inner query (src) selects only the three columns the pivot needs. This matters a lot, and we come back to it below.
• SUM(Revenue) is the aggregate that fills each cell. Laptop’s two Q1 rows add up to 120.
• FOR Quarter IN (...) names the pivot column and lists the values that become headings. You must list them by hand. Square brackets are required for names that contain spaces or start with a digit.
• AS p gives the pivot result an alias, which SQL Server requires.

After executing the above query, I got the expected output as shown in the screenshot below.

The output matches the table above. Missing combinations, like Monitor Q2, appear as NULL because no row existed to aggregate. A NULL is a missing or unknown value, not zero. To show zeros, wrap each column with COALESCE, which returns the first non-NULL value; see the COALESCE function and how SQL handles NULL.

SELECT Product,
       COALESCE([Q1], 0) AS Q1,
       COALESCE([Q2], 0) AS Q2,
       COALESCE([Q3], 0) AS Q3,
       COALESCE([Q4], 0) AS Q4
FROM (SELECT Product, Quarter, Revenue FROM dbo.QuarterlySales) AS src
PIVOT (SUM(Revenue) FOR Quarter IN ([Q1], [Q2], [Q3], [Q4])) AS p;

After executing the above query, I got the expected output as shown in the screenshot below.

The Hidden-Column Trap

PIVOT groups by every column in the source that is not the pivot column or the value column. If you write SELECT * FROM dbo.QuarterlySales PIVOT (...), the unique SaleID becomes part of the grouping, and every row ends up on its own line with mostly NULLs. Always use a subquery that selects only the columns you need, as shown above.

Pro Tip: I once debugged a report that returned ten times too many rows because someone added a LastModified column to the source. Selecting exactly three columns in the inner query protects you from that kind of drift.

Method 2: Conditional Aggregation With CASE

You can get the same result with ordinary GROUP BY and CASE. This is called conditional aggregation: each column sums only the rows that match its heading. See the CASE statement, the SUM function, and GROUP BY.

SELECT
    Product,
    SUM(CASE WHEN Quarter = 'Q1' THEN Revenue ELSE 0 END) AS Q1,
    SUM(CASE WHEN Quarter = 'Q2' THEN Revenue ELSE 0 END) AS Q2,
    SUM(CASE WHEN Quarter = 'Q3' THEN Revenue ELSE 0 END) AS Q3,
    SUM(CASE WHEN Quarter = 'Q4' THEN Revenue ELSE 0 END) AS Q4
FROM dbo.QuarterlySales
GROUP BY Product
ORDER BY Product;

After executing the above query, I got the expected output as shown in the screenshot below.

Each CASE returns the revenue when the row belongs to that quarter and 0 otherwise. SUM adds them up per product. The ELSE 0 gives zeros instead of NULLs. If you leave out ELSE, missing combinations come back as NULL.

PIVOT vs. CASE

Both read the table once, so performance is usually similar. I use PIVOT for quick one-aggregate layouts and CASE when a report needs counts, sums, and custom rules side by side. Pick the one your team can maintain.

Pro Tip: In my experience, teams that learn conditional aggregation first rarely need PIVOT. It handles more cases, and it ports to other databases if you ever migrate.

Method 3: Dynamic Pivot When Columns Change

Both methods above hard-code the headings. That breaks the day a new value appears, such as Q5 or a new region. When the list of values changes, build the column list from the data with dynamic SQL, which means assembling a SQL statement as text and running it at run time. Read more in dynamic SQL.

DECLARE @cols NVARCHAR(MAX), @sql NVARCHAR(MAX);

SELECT @cols = STRING_AGG(CAST(QUOTENAME(Quarter) AS NVARCHAR(MAX)), N', ')
               WITHIN GROUP (ORDER BY Quarter)
FROM (SELECT DISTINCT Quarter FROM dbo.QuarterlySales) AS q;

SET @sql = N'
SELECT Product, ' + @cols + N'
FROM (SELECT Product, Quarter, Revenue FROM dbo.QuarterlySales) AS src
PIVOT (SUM(Revenue) FOR Quarter IN (' + @cols + N')) AS p
ORDER BY Product;';

EXEC sys.sp_executesql @sql;

Step by step:

• SELECT DISTINCT Quarter finds the headings that exist right now.
• QUOTENAME wraps each value in brackets and escapes special characters. This is essential for safety and for names with spaces. See QUOTENAME.
• STRING_AGG joins the values into a comma-separated list, ordered with WITHIN GROUP. It requires SQL Server 2017 or later and is available in Azure SQL Database. See STRING_AGG. On older versions, the FOR XML PATH trick is the traditional replacement.
• sp_executesql runs the generated statement.

After executing the above query, I got the expected output as shown in the screenshot below.

Dynamic SQL carries risks. If any heading value comes from user input, an attacker could try SQL injection, which means slipping extra SQL commands into the text. QUOTENAME neutralizes this for identifiers, but never concatenate raw user input anywhere else in the statement.

Also remember that dynamic SQL does not benefit from ownership chaining, the rule that lets a procedure access tables its owner can access without extra grants. The caller needs permission on the underlying table, or the procedure must use EXECUTE AS.

Wide results have limits too. A result set can hold a large number of columns, but a report with hundreds of dynamic columns is hard to read and slow to render. If the headings number in the dozens, consider doing the final layout in the reporting tool or application.

Pro Tip: I log the generated @sql text to a debug table during testing. Seeing the exact statement makes dynamic pivot bugs obvious in seconds, instead of staring at a string in a debugger.

Pivot Dates and Months

Real reports often pivot dates. Raw dates make poor headings, because every day would become a column. Convert them to a month or a quarter first:

SELECT Product,
       SUM(CASE WHEN MONTH(SaleDate) = 1 THEN Revenue ELSE 0 END) AS Jan,
       SUM(CASE WHEN MONTH(SaleDate) = 2 THEN Revenue ELSE 0 END) AS Feb,
       SUM(CASE WHEN MONTH(SaleDate) = 3 THEN Revenue ELSE 0 END) AS Mar
FROM dbo.DailySales
WHERE SaleDate >= '2026-01-01' AND SaleDate < '2026-04-01'
GROUP BY Product;

This assumes a DailySales table with a SaleDate column. The date filter uses a half-open range, which includes January 1 and excludes April 1, and it keeps the column bare so SQL Server can use an index. For month functions, see getting the month from a date. For the full date-pivot pattern, read pivoting a date column.

Turn Rows Into a Single Column

Sometimes “rows into columns” means joining many rows into one text value, such as a comma-separated list of tags. That is a different task. Use STRING_AGG:

SELECT Product, STRING_AGG(Quarter, ', ') WITHIN GROUP (ORDER BY Quarter) AS QuartersSold
FROM dbo.QuarterlySales
GROUP BY Product;

This returns lines such as “Q1, Q1, Q2, Q3, Q4” for Laptop. Use SELECT DISTINCT in a subquery if you want each quarter once. The result is text, so you can no longer aggregate it, which is why this approach suits display and exports more than analysis.

Performance, Indexing, and Reuse

A pivot reads the source rows once, groups them, and spreads values across columns. The cost depends mostly on how many rows you scan, not on the pivot itself. To keep it fast:

• Filter first. Restrict by date or tenant in the source subquery so you pivot fewer rows.
• Index the grouping and filter columns. An index on (Product, Quarter) that includes Revenue lets SQL Server read a narrow structure. See how to create an index in SQL Server. Check the actual execution plan first, because each index slows inserts and updates.
• Pre-aggregate large tables. For hundreds of millions of rows, keep a summary table updated nightly and pivot that instead.
• Use a CTE for clarity. A common table expression names an intermediate step; compare it with a temp table in CTE vs. temp table.

Save the final query in a view or a stored procedure so every report uses the same layout; see SQL Server views and creating a stored procedure. For more tuning ideas, see SQL query optimization tips. In Azure SQL Database, use Query Store, which records query run times, to confirm that a change helped.

Pro Tip: In my experience, the best pivot optimization is a date filter. Pivoting five years of history to show the last quarter wastes compute, which on serverless Azure SQL Database also wastes money.

Frequently Asked Questions

How do I convert rows into columns in SQL Server?

Use the PIVOT operator, or use GROUP BY with SUM(CASE WHEN ... THEN ... END) for each new column. Both turn distinct values from one column into column headings and aggregate a value column into the cells.

What is the difference between PIVOT and CASE for pivoting?

PIVOT is shorter for one aggregate across many columns. CASE is more flexible because you can use several aggregates and custom logic per column, and it works in most SQL dialects. Performance is usually similar.

How do I pivot when I do not know the column values in advance?

Build the column list from the data with STRING_AGG and QUOTENAME, assemble a dynamic PIVOT statement, and run it with sp_executesql. Validate inputs, and remember that the caller needs permission on the underlying table.

Why does my PIVOT return duplicate rows or too many rows?

The source includes extra columns, such as an ID, and PIVOT groups by all of them. Select only the row identifier, pivot column, and value column in a subquery.

How do I show zero instead of NULL in a pivot?

Wrap each pivoted column in COALESCE(column, 0), or use ELSE 0 inside the CASE expressions. Decide whether zero is accurate, since NULL can mean no data and zero means no sales.

You learned how to convert rows into columns in SQL Server with PIVOT, conditional aggregation, and dynamic SQL, and how to handle NULLs, hidden grouping columns, and changing headings. Select only the columns the pivot needs, protect dynamic SQL with QUOTENAME, and give report users read-only access through a view. I hope you found this article helpful.

You May Also Like

• SQL Server string split into rows
• Converting JSON to a table in SQL Server
• How to group by date in SQL Server
• How to use the COUNT function in SQL Server
• SQL cheat sheet

That expression was CASE WHEN, and learning how to use CASE WHEN in SQL Server is one of the best investments a developer or analyst can make. It adds if/then logic directly inside a query, so labels, buckets, custom sorting, and conditional totals all come from the database in one pass. This guide covers both forms of CASE, the common patterns, the NULL and data-type traps, performance, and safe use in production on SQL Server or Azure SQL Database.

What CASE Does and the Two Forms

CASE is an expression, not a statement. That means it returns a value and can be used anywhere a value is allowed: in SELECT, WHERE, ORDER BY, GROUP BY, aggregates, and UPDATE. SQL Server evaluates the conditions from top to bottom and returns the result for the first one that is true.

There are two forms.

Simple CASE compares one expression to a list of values:

CASE Status
    WHEN 'Shipped' THEN 'Done'
    WHEN 'Pending' THEN 'Open'
    ELSE 'Other'
END

Searched CASE tests full conditions, so it handles ranges, AND/OR, and NULL checks:

CASE
    WHEN Amount < 100 THEN 'Small'
    WHEN Amount < 500 THEN 'Medium'
    ELSE 'Large'
END

Use simple CASE for exact matches and searched CASE for everything else. If you leave out ELSE and no condition matches, the result is NULL. Always add an ELSE unless NULL is truly what you want.

Pro Tip: In my experience, I default to the searched form even for exact matches. It costs nothing, and it avoids a rewrite when someone asks for a range or a NULL check later.

Create a Practice Table

A schema is the structure of your tables. Use a small orders table with edge cases: a NULL amount, mixed statuses, and values on both sides of each band.

CREATE TABLE dbo.Orders (
    OrderID    INT IDENTITY(1,1) PRIMARY KEY,
    CustomerID INT NOT NULL,
    Amount     DECIMAL(10,2) NULL,
    Status     VARCHAR(20) NOT NULL,
    OrderDate  DATE NOT NULL
);

INSERT INTO dbo.Orders (CustomerID, Amount, Status, OrderDate)
VALUES
 (101,   45.00, 'Shipped',   '2026-10-01'),
 (102,  250.00, 'Pending',   '2026-10-03'),
 (103, 1200.00, 'Shipped',   '2026-10-05'),
 (101,    NULL, 'Cancelled', '2026-10-06'),
 (104,   89.99, 'Returned',  '2026-10-08'),
 (105,  600.00, 'Pending',   '2026-10-09');

Run this only in a test database, because it inserts rows. Order 4 has a NULL amount on purpose.

After executing the query above, I got the expected output as shown in the screenshot below.

How to Use CASE WHEN in SQL Server SELECT Queries

The most common use is creating a label column. This query puts each order in a size band:

SELECT
    OrderID,
    Amount,
    CASE
        WHEN Amount IS NULL THEN 'No amount'
        WHEN Amount < 100   THEN 'Small'
        WHEN Amount < 500   THEN 'Medium'
        ELSE 'Large'
    END AS OrderSize
FROM dbo.Orders;

After executing the query above, I got the expected output as shown in the screenshot below.

The results are Small, Medium, Large, No amount, Small, and Large for orders 1 to 6. Notice three details:

• Order matters. SQL Server returns the first true branch. Because Amount < 100 comes before Amount < 500, an order of 45 is Small, even though it is also below 500. If you reverse them, everything below 500 becomes Medium.
• The NULL check comes first. A NULL amount makes both Amount < 100 and Amount < 500 unknown, not true, so it would fall through to ELSE and be labeled Large. That is a silent bug. For more on this behavior, see how SQL handles NULL.
• Aliases name the result. AS OrderSize gives the new column a readable name.

You can also translate codes with a simple CASE:

SELECT OrderID,
       CASE Status
           WHEN 'Shipped'   THEN 'Complete'
           WHEN 'Pending'   THEN 'In progress'
           WHEN 'Cancelled' THEN 'Closed'
           WHEN 'Returned'  THEN 'Closed'
           ELSE 'Unknown'
       END AS StatusGroup
FROM dbo.Orders;

After executing the query above, I got the expected output as shown in the screenshot below.

Keeping this mapping in one query, or better in a view, prevents the “app and report disagree” problem. See SQL Server views.

Pro Tip: I write the NULL branch first in every searched CASE. It takes one line and removes a whole class of “why is this row in the wrong bucket” bugs.

The NULL Trap: = NULL Never Matches

This is the number one mistake. Inside CASE, WHEN Amount = NULL is never true, because comparing with NULL gives unknown.

-- Wrong: never matches
CASE WHEN Amount = NULL THEN 'No amount' ELSE 'Has amount' END

-- Right
CASE WHEN Amount IS NULL THEN 'No amount' ELSE 'Has amount' END

The same trap exists in simple CASE. CASE Amount WHEN NULL THEN ... also never matches, because the simple form uses equality. Use the searched form with IS NULL.

For shorter NULL handling, COALESCE and ISNULL often replace a whole CASE; see COALESCE and ISNULL. For choosing between them, read NULLIF vs. COALESCE.

Use CASE in ORDER BY for Custom Sorting

Alphabetical order is rarely the business order. CASE in ORDER BY lets you define your own ranking:

SELECT OrderID, Status, OrderDate
FROM dbo.Orders
ORDER BY
    CASE Status
        WHEN 'Pending'   THEN 1
        WHEN 'Shipped'   THEN 2
        WHEN 'Returned'  THEN 3
        WHEN 'Cancelled' THEN 4
        ELSE 5
    END,
    OrderDate DESC;

After executing the query above, I got the expected output as shown in the screenshot below.

The CASE maps each status to a number, and SQL Server sorts by that number first. Pending orders appear at the top, then Shipped, Returned, and Cancelled, with the newest order first inside each group. See ORDER BY in SQL Server for the basics.

A second use is putting NULLs last. SQL Server sorts NULLs first in ascending order, so this flips that:

sqlORDER BY CASE WHEN Amount IS NULL THEN 1 ELSE 0 END, Amount;

The first sort key is 0 for rows with an amount and 1 for NULL rows, so NULLs fall to the end.

Conditional Aggregation: Pivot-Style Reports

You can place CASE inside an aggregate function to count or sum only certain rows. This is called conditional aggregation, and it replaces many separate queries with one. See the SUM function and GROUP BY.

SELECT
    COUNT(*) AS TotalOrders,
    SUM(CASE WHEN Status = 'Shipped'   THEN 1 ELSE 0 END) AS ShippedCount,
    SUM(CASE WHEN Status = 'Pending'   THEN 1 ELSE 0 END) AS PendingCount,
    SUM(CASE WHEN Status = 'Shipped'   THEN Amount ELSE 0 END) AS ShippedRevenue,
    SUM(CASE WHEN Status = 'Pending'   THEN Amount ELSE 0 END) AS PendingRevenue
FROM dbo.Orders;

After executing the query above, I got the expected output as shown in the screenshot below.

With the sample data, this returns 6 total orders, 2 shipped, 2 pending, 1,245.00 in shipped revenue, and 850.00 in pending revenue. Each CASE returns 1 or the amount when the row qualifies and 0 otherwise, and SUM adds the results.

Use SUM(CASE ... THEN 1 ELSE 0 END), not COUNT(CASE ... THEN 1 ELSE 0 END). COUNT counts every non-NULL value, so 0 is counted too. If you want COUNT, omit the ELSE so non-matching rows become NULL. For more on COUNT, see the COUNT function.

For a full pivot with dynamic columns, SQL Server also has a PIVOT operator; see pivoting rows to columns. Conditional aggregation is often easier to read and works with any version.

Pro Tip: I use conditional aggregation for dashboards because one query returns every tile. Ten small queries each scan the table; one CASE-based query scans it once.

Use CASE in UPDATE Statements

CASE lets one UPDATE apply different values to different rows.

Warning: UPDATE overwrites data. Take a backup, preview with a SELECT, and use a transaction. See table backup in SQL Server.

-- Preview first
SELECT OrderID, Status,
       CASE WHEN Status = 'Pending' AND OrderDate < '2026-10-05'
            THEN 'Delayed' ELSE Status END AS NewStatus
FROM dbo.Orders;

BEGIN TRANSACTION;

UPDATE dbo.Orders
SET Status = CASE
                 WHEN Status = 'Pending' AND OrderDate < '2026-10-05' THEN 'Delayed'
                 ELSE Status
             END
WHERE Status = 'Pending';

SELECT @@ROWCOUNT AS RowsUpdated;

-- COMMIT TRANSACTION;   -- after verifying the count
-- ROLLBACK TRANSACTION; -- to undo

After executing the query above, I got the expected output as shown in the screenshot below.

The preview shows exactly what will change. The WHERE Status = 'Pending' limits the rows the update touches, and ELSE Status keeps the original value for rows that do not match. Without the WHERE, SQL Server would rewrite every row, including unchanged ones, which wastes log space and takes more locks.

Check @@ROWCOUNT before you commit, and keep the transaction short to avoid blocking other sessions. When the new values come from another table, see updating a table from another table.

Pitfalls: Data Types, Evaluation Order, and Division

Return types must be compatible. Every THEN and ELSE result in one CASE must resolve to a single data type, chosen by SQL Server’s data type precedence, the ranking that decides which type wins when types are mixed. If one branch returns a number and another returns text, SQL Server tries to convert the text to a number and fails:

-- Fails when the ELSE branch is reached: 'Unknown' cannot become an INT
SELECT CASE WHEN Amount > 100 THEN 1 ELSE 'Unknown' END FROM dbo.Orders;

Make the types match, for example by casting the number to text. See the CAST function and the related error converting varchar to numeric.

Guard division, but know the limits. CASE is the standard way to avoid divide-by-zero:

SELECT CASE WHEN Amount = 0 OR Amount IS NULL THEN NULL
            ELSE 100.0 / Amount END AS Ratio
FROM dbo.Orders;

SQL Server generally evaluates CASE branches in order, but the documentation warns that it does not guarantee evaluation order in every case, especially when aggregates appear inside the expression. For simple division, NULLIF is shorter and safer: 100.0 / NULLIF(Amount, 0).

Nesting has a limit. SQL Server allows CASE expressions to nest up to 10 levels. If you need that many, move the rules into a lookup table and join to it. A mapping table is easier to change than code; see joins in SQL Server.

Know the alternatives. IIF is shorthand for a two-branch CASE; see the IIF function. CHOOSE picks from a list by position; see the CHOOSE function. Use CASE when you have more than two outcomes or need the clearest logic.

Pro Tip: I once reviewed a CASE with twelve nested levels that nobody on the team dared touch. We replaced it with a six-row lookup table, and the next rule change took two minutes.

Use CASE in WHERE and Keep Queries Fast

You can place CASE in a WHERE clause, but you usually should not. Compare these two queries:

-- Hard for the optimizer: the column is hidden inside an expression
SELECT OrderID FROM dbo.Orders
WHERE CASE WHEN Status = 'Shipped' THEN 1 ELSE 0 END = 1;

-- Better: a plain, index-friendly condition
SELECT OrderID FROM dbo.Orders
WHERE Status = 'Shipped';

A condition is sargable when SQL Server can use an index seek to find matching rows. Wrapping a column in a CASE or function usually makes it non-sargable, which forces a scan. Use ordinary AND/OR conditions in WHERE; see the WHERE condition. Reserve CASE for the SELECT list, ORDER BY, and aggregates.

When you do filter on a computed bucket often, an index on the base column helps, and a computed column can store the label. Create indexes only after checking the actual execution plan; see how to create an index in SQL Server and SQL query optimization tips. Every index slows writes and takes storage.

In Azure SQL Database, use Query Store, which records query run times and plans, to confirm that a rewrite helped.

Pro Tip: In my experience, CASE itself is rarely the performance problem. The slow part is almost always putting it in WHERE or joining on its result against a big table.

Secure and Test CASE-Based Reports

Reports that bucket customers or flag risk are business logic, so treat them like code.

1. Put shared rules in a view or stored procedure so every report uses the same definition.
2. Use a least-privilege reporting user. Grant SELECT on the view only. See how to grant SELECT.
3. Use Microsoft Entra ID authentication and managed identities instead of SQL passwords in scripts.
4. Require encrypted connections. Verify with SELECT encrypt_option FROM sys.dm_exec_connections WHERE session_id = @@SPID;.
5. Test boundaries. Include values at each band edge, plus NULLs, in your test data.

CREATE USER [orders-report] FROM EXTERNAL PROVIDER;
GRANT SELECT ON OBJECT::dbo.vw_OrderSize TO [orders-report];

FROM EXTERNAL PROVIDER creates a contained database user mapped to an Entra identity, so no password is stored. The grant allows reading one view. If a bad UPDATE ... CASE ever damages data, Azure SQL Database supports point-in-time restore into a new database, so you can compare and copy back correct values. Confirm your retention window in advance.

CASE WHEN Quality Checklist

• Order your branches. The first true condition wins, so put narrow rules before broad ones.
• Handle NULL explicitly. Use IS NULL, never = NULL, and put that branch first.
• Always add ELSE. A missing ELSE quietly returns NULL.
• Match result types. Every branch must convert to one compatible data type.
• Keep CASE out of WHERE. Use plain conditions to preserve index seeks.
• Preview before updating. Run the SELECT, use a transaction, and check @@ROWCOUNT.

Frequently Asked Questions

What is CASE WHEN in SQL Server?

CASE WHEN is a conditional expression that returns different values based on conditions. It evaluates WHEN tests in order and returns the result of the first true one, or the ELSE value if none match. You can use it in SELECT, ORDER BY, GROUP BY, aggregates, and UPDATE.

What is the difference between simple and searched CASE?

Simple CASE compares one expression to a list of values for equality. Searched CASE evaluates full Boolean conditions, so it handles ranges, AND/OR, and IS NULL. Searched CASE is more flexible and is the safer default.

How do I handle NULL in CASE WHEN?

Use WHEN column IS NULL, not = NULL, and place it first so NULL rows do not fall into ELSE. For simple replacements, COALESCE or ISNULL may be shorter.

Can I use CASE WHEN in a WHERE clause?

Yes, but it often prevents index seeks and slows queries. Prefer ordinary conditions with AND and OR in WHERE, and use CASE in the select list, ORDER BY, or aggregates.

How many conditions can a CASE statement have?

There is no small fixed limit on the number of WHEN branches, but CASE expressions can nest only up to 10 levels. If you need dozens of rules, move them into a lookup table and join to it.

You learned how to use CASE WHEN in SQL Server for labels, custom sorting, conditional totals, and updates, and how to avoid NULL, data type, and performance traps. Put the NULL branch first, always include ELSE, and preview every UPDATE with a SELECT and a transaction before you commit. I hope you found this article helpful.

You May Also Like

• SQL SELECT query examples
• SQL Server TOP clause
• SQL wildcard characters
• How to use IF ELSE in a SQL Server stored procedure
• SQL cheat sheet

That is the most common trap when you learn how to find percentage of total in SQL. The idea is simple: divide each part by the whole. Getting it right means choosing the right way to compute the whole, handling integer math and zero totals, and deciding what “total” means after filters and groups. This guide builds the answer step by step in T-SQL, then covers performance and secure reporting in SQL Server and Azure SQL Database.

Create a Practice Table

A schema is the structure of your tables. Use a small sales table so you can check every result by hand.

CREATE TABLE dbo.Sales (
    SalesID  INT IDENTITY(1,1) PRIMARY KEY,
    Region   VARCHAR(20)   NOT NULL,
    Category VARCHAR(20)   NOT NULL,
    Amount   DECIMAL(10,2) NOT NULL
);

INSERT INTO dbo.Sales (Region, Category, Amount)
VALUES
 ('West',  'Hardware', 1200.00),
 ('West',  'Software',  800.00),
 ('East',  'Hardware',  600.00),
 ('East',  'Software', 1400.00),
 ('South', 'Hardware',  500.00),
 ('South', 'Software',  500.00);

After executing the above query, I got the expected output as shown in the screenshot below.

Run this only in a test database, because it inserts rows. The grand total is 5,000. Region totals are West 2,000, East 2,000, and South 1,000, so the expected shares are 40, 40, and 20 percent. Category totals are Hardware 2,300 (46 percent) and Software 2,700 (54 percent). Knowing the answers up front lets you verify each query.

Pro Tip: In my experience, a six-row table with totals you can add in your head catches more percentage bugs than a million-row production table. I always verify the logic on tiny data first.

The Basic Idea and the Integer Division Trap

A percentage of total is part / total * 100. In T-SQL, the data type of the operands decides how division behaves. If both sides are integers, SQL Server performs integer division and drops the remainder.

SELECT 1200 / 5000 * 100      AS WrongPercent,   -- 0
       1200 * 100.0 / 5000    AS RightPercent;   -- 24.000000

After executing the above query, I got the expected output as shown in the screenshot below.

The first expression divides 1200 by 5000 and gets 0 because both are integers, then multiplies 0 by 100. The second multiplies by 100.0 first, which makes the whole expression decimal. Always start with 100.0 or cast a value to DECIMAL before dividing. For more on conversions, see the CAST function.

This is exactly what broke the finance dashboard. In our table Amount is already DECIMAL, but in many real tables the measure is an INT count.

How to Find Percentage of Total in SQL With a Subquery

The oldest method computes the total in a separate query. A scalar subquery returns a single value and can be used inside another query. See SQL subqueries.

SELECT
    SalesID,
    Region,
    Amount,
    CAST(Amount * 100.0 / (SELECT SUM(Amount) FROM dbo.Sales) AS DECIMAL(5,2)) AS PctOfTotal
FROM dbo.Sales
ORDER BY SalesID;

After executing the above query, I got the expected output as shown in the screenshot below.

The inner SELECT SUM(Amount) calculates 5,000 once, and each row divides by it. Results are 24.00, 16.00, 12.00, 28.00, 10.00, and 10.00. They add up to 100.

This approach works on any SQL Server version and is easy to read. The trade-off is that SQL Server reads the table for the main query and again for the total. On small tables that is trivial. On big tables the second scan adds cost. For the SUM function itself, see how to use SUM in SQL Server.

Use a Window Function for the Cleanest Result

A window function calculates across a set of rows without collapsing them. With SUM(Amount) OVER (), the empty parentheses mean “the whole result set.” Read more in window functions in SQL Server and the OVER clause.

SELECT
    SalesID,
    Region,
    Amount,
    CAST(Amount * 100.0 / SUM(Amount) OVER () AS DECIMAL(5,2)) AS PctOfTotal
FROM dbo.Sales
ORDER BY SalesID;

After executing the above query, I got the expected output as shown in the screenshot below.

This returns the same numbers as the subquery version. SQL Server calculates the total in the same pass and attaches it to every row. The query is shorter, and it avoids repeating the table name. This is the method I recommend for most reports.

Protect Against Divide-by-Zero

If the total is zero, for example when a filter returns no sales or all amounts net to zero, you get a divide-by-zero error. Use NULLIF, which returns NULL when two values are equal, so the division returns NULL instead of failing. See NULLIF vs. COALESCE.

SELECT
    Region,
    Amount,
    CAST(Amount * 100.0 / NULLIF(SUM(Amount) OVER (), 0) AS DECIMAL(5,2)) AS PctOfTotal
FROM dbo.Sales;

After executing the above query, I got the expected output as shown in the screenshot below.

When the total is 0, the denominator becomes NULL and the percentage is NULL. Decide whether the report should show NULL, 0, or a message. Wrap with COALESCE if you want zero.

Pro Tip: I once watched a nightly report fail because a single region had no sales on a holiday. Adding NULLIF to every denominator is now a habit, not an afterthought.

Percentage of Total by Group

Business questions usually ask for shares by region or category, not by row. Combine GROUP BY with a window function over the grouped results. See how to use GROUP BY in SQL Server.

SELECT
    Region,
    SUM(Amount) AS RegionSales,
    CAST(SUM(Amount) * 100.0 / SUM(SUM(Amount)) OVER () AS DECIMAL(5,2)) AS PctOfTotal
FROM dbo.Sales
GROUP BY Region
ORDER BY RegionSales DESC;

After executing the above query, I got the expected output as shown in the screenshot below.

The inner SUM(Amount) is the group total. The outer SUM(... ) OVER () adds those group totals together to get the grand total. This works because window functions run after GROUP BY. The result is West 40.00, East 40.00, and South 20.00.

The nested SUM(SUM(...)) looks odd the first time you see it. If it confuses your team, use a CTE (common table expression), a named temporary result you can query immediately. Compare it with a temp table in CTE vs. temp table.

WITH RegionTotals AS (
    SELECT Region, SUM(Amount) AS RegionSales
    FROM dbo.Sales
    GROUP BY Region
)
SELECT
    Region,
    RegionSales,
    CAST(RegionSales * 100.0 / SUM(RegionSales) OVER () AS DECIMAL(5,2)) AS PctOfTotal
FROM RegionTotals
ORDER BY RegionSales DESC;

After executing the above query, I got the expected output as shown in the screenshot below.

It returns the same result in two clear steps: aggregate first, then calculate the share.

Pro Tip: I use the CTE version when the query will be maintained by someone else. Two readable steps beat one clever expression that nobody wants to touch.

Percentage Within a Group

Sometimes the “whole” is a subgroup. For example, you want each category’s share within its region. Add PARTITION BY to the window, which restarts the calculation for each group. See PARTITION BY.

SELECT
    Region,
    Category,
    SUM(Amount) AS CategorySales,
    CAST(SUM(Amount) * 100.0
         / SUM(SUM(Amount)) OVER (PARTITION BY Region) AS DECIMAL(5,2)) AS PctOfRegion
FROM dbo.Sales
GROUP BY Region, Category
ORDER BY Region, Category;

With PARTITION BY Region, the denominator is that region’s total. The output is East Hardware 30.00 and Software 70.00, South 50.00 and 50.00, and West Hardware 60.00 and Software 40.00. Each region’s percentages add to 100.

Be clear about which total you are using. The three versions you may need are percent of the grand total, percent of the group, and percent of a filtered set. Label the column so readers know, for example PctOfRegion rather than just Pct.

Combine Percentages With Filters Correctly

Filters change the denominator. This catches many people. A WHERE clause runs before window functions, so the total only includes the filtered rows.

-- Percent of Hardware sales only (denominator excludes Software)
SELECT Region,
       SUM(Amount) AS HardwareSales,
       CAST(SUM(Amount) * 100.0 / SUM(SUM(Amount)) OVER () AS DECIMAL(5,2)) AS PctOfHardware
FROM dbo.Sales
WHERE Category = 'Hardware'
GROUP BY Region;

Here the total is 2,300, not 5,000. If you want each region’s Hardware sales as a share of all sales, calculate the percentage first and filter afterward:

WITH Shares AS (
    SELECT Region, Category, Amount,
           Amount * 100.0 / SUM(Amount) OVER () AS PctOfGrandTotal
    FROM dbo.Sales
)
SELECT Region, Category, CAST(PctOfGrandTotal AS DECIMAL(5,2)) AS PctOfGrandTotal
FROM Shares
WHERE Category = 'Hardware';

The CTE calculates shares against all 5,000, then the outer WHERE filters the rows. The difference between WHERE before and after the window is explained further in HAVING vs. WHERE.

Pro Tip: When a stakeholder says “the numbers don’t add up,” I ask one question: “Percent of what?” Nine times out of ten the filter changed the denominator.

Add a Cumulative Percentage

A running total of percentages shows how fast sales accumulate, which supports Pareto-style questions like “which regions make up 80 percent of revenue?”

WITH RegionTotals AS (
    SELECT Region, SUM(Amount) AS RegionSales
    FROM dbo.Sales
    GROUP BY Region
)
SELECT
    Region,
    RegionSales,
    CAST(SUM(RegionSales) OVER (ORDER BY RegionSales DESC, Region
                                ROWS UNBOUNDED PRECEDING) * 100.0
         / SUM(RegionSales) OVER () AS DECIMAL(5,2)) AS CumulativePct
FROM RegionTotals
ORDER BY RegionSales DESC, Region;

The window with ORDER BY and ROWS UNBOUNDED PRECEDING adds up values from the first row to the current one. With ties between West and East, the tie-breaker Region keeps the order stable. The result is West 40.00, East 80.00, and South 100.00. Always specify the ROWS frame explicitly; the default frame can behave differently with ties and is usually slower.

Format and Round the Results

Keep percentages numeric in the database and format them in the application when possible. If you need text in T-SQL, use CAST and CONCAT:

SELECT Region,
       CONCAT(CAST(SUM(Amount) * 100.0 / SUM(SUM(Amount)) OVER () AS DECIMAL(5,1)), '%') AS Share
FROM dbo.Sales
GROUP BY Region;

For more on rounding, see formatting numbers to two decimal places. Be aware that rounded values may not sum to exactly 100. Three shares of 33.33 add to 99.99. That is normal. If an exact 100 is required, adjust the largest item or round only at display time and explain that totals may differ slightly.

Make It Fast and Reusable

A window over the whole result must see every row to compute the total, so these queries scan or aggregate the data they use. Three habits keep them fast:

• Aggregate before windowing. The grouped version works on a few rows after GROUP BY, not thousands of detail rows.
• Index the columns involved. An index on Region that includes Amount lets SQL Server read a narrow structure. See how to create an index in SQL Server. Check the execution plan first, because every index slows inserts and updates.
• Pre-aggregate for dashboards. If a report reads hundreds of millions of rows, store daily or monthly totals in a summary table and calculate percentages from that.

For large analytic tables, a columnstore index, which stores data by column and compresses it, can speed aggregations. Test it against your workload first. For more tips, see SQL query optimization tips.

Package the logic in a view so every report uses the same definition of “percent of total.” See SQL Server views.

CREATE OR ALTER VIEW dbo.vw_RegionShare
AS
SELECT
    Region,
    SUM(Amount) AS RegionSales,
    CAST(SUM(Amount) * 100.0 / NULLIF(SUM(SUM(Amount)) OVER (), 0) AS DECIMAL(5,2)) AS PctOfTotal
FROM dbo.Sales
GROUP BY Region;

Pro Tip: In my experience, definitions drift when ten reports each calculate their own percentage. A single view makes the denominator an agreed business rule.

Frequently Asked Questions

How do I calculate percentage of total in SQL Server?

Divide each value by the total and multiply by 100.0, for example Amount * 100.0 / SUM(Amount) OVER (). The empty OVER () makes the window cover the whole result, so every row gets the grand total.

Why does my percentage of total return 0?

You are probably dividing two integers, and SQL Server drops the decimals. Multiply by 100.0 before dividing or cast one value to DECIMAL.

How do I calculate percentage within each group?

Use PARTITION BY in the window, such as SUM(Amount) OVER (PARTITION BY Region). The denominator then becomes each group’s total, and the percentages in each group add to 100.

How do I avoid divide-by-zero errors?

Wrap the denominator in NULLIF(total, 0). When the total is zero, the result becomes NULL instead of an error, and you can replace it with COALESCE if you prefer zero.

Is a subquery or a window function better for percent of total?

Both give the same answer. The window function is shorter and calculates the total in the same pass, while a scalar subquery works on every version and is easy to read. For large tables, compare execution plans.

You learned how to find percentage of total in SQL using subqueries, window functions, grouped totals, and PARTITION BY, and how to avoid integer division and divide-by-zero errors. Name your denominator clearly, verify results against a hand-calculated total, and give report users read-only access through a view. I hope you found this article helpful.

You May Also Like

• How to use the AVG function in SQL Server
• How to use the COUNT function in SQL Server
• RANK vs. DENSE_RANK in SQL
• SQL Server FLOOR function
• How to group by date in SQL Server

That mistake is one of the most common in T-SQL, and it is why learning how to find null values in a table in SQL Server matters. The right operator is only the start. You also need to count NULLs per column, tell them apart from empty strings, find them across an entire table, and decide what to do next. This guide covers each of those tasks with T-SQL, then shows how to speed up NULL searches and run them safely in SQL Server or Azure SQL Database.

What NULL Means in SQL Server

A NULL is a marker for a missing or unknown value. It is not zero, not an empty string, and not a space. Because NULL means “unknown,” SQL Server uses three-valued logic: a comparison can be true, false, or unknown. Any normal comparison with NULL, such as Email = NULL or Email <> 'a@b.com', evaluates to unknown, and a WHERE clause only keeps rows that evaluate to true. That is why the analyst’s query returned nothing.

For a deeper look, see how SQL handles NULL.

Pro Tip: In my experience, most NULL bugs come from treating NULL like a value. I say “unknown” out loud when I read a query, and it makes the wrong operators stand out.

Create a Practice Table

Test on a small table with deliberate edge cases. A schema is the structure of your tables, and sample rows that include NULLs, empty strings, and the text “NULL” will show you every trap.

CREATE TABLE dbo.Customers (
    CustomerID    INT IDENTITY(1,1) PRIMARY KEY,
    FullName      VARCHAR(100) NOT NULL,
    Email         VARCHAR(150) NULL,
    Phone         VARCHAR(30)  NULL,
    Region        VARCHAR(30)  NULL,
    LastOrderDate DATE         NULL
);

INSERT INTO dbo.Customers (FullName, Email, Phone, Region, LastOrderDate)
VALUES
 ('Ava Chen',    'ava@example.com', '555-0101', 'West',  '2026-10-02'),
 ('Ben Ortiz',   NULL,              '555-0102', 'East',  '2026-09-18'),
 ('Cara Singh',  '',                NULL,       'West',  NULL),
 ('Dan Weber',   'NULL',            '555-0104', NULL,    '2026-08-30'),
 ('Eli Brooks',  NULL,              NULL,       NULL,    NULL);

After executing the query above, I got the expected output as shown in the screenshot below.

Run this only in a test database, because it inserts rows. Notice that Cara’s email is an empty string, Dan’s email is the five-letter text NULL, and Eli has missing values in four columns. Only Ben’s and Eli’s emails are real NULLs.

How to Find NULL Values in a Table in SQL Server With IS NULL

Use IS NULL to find rows where a column is missing, and IS NOT NULL for rows that have a value. These are the only comparison operators that work with NULL. See also the WHERE clause tutorial.

-- Customers with no email on file
SELECT CustomerID, FullName, Email
FROM dbo.Customers
WHERE Email IS NULL;

After executing the query above, I got the expected output as shown in the screenshot below.

This returns Ben and Eli. It does not return Cara (empty string) or Dan (text “NULL”), which are values, not NULLs. To list customers who do have an email:

SELECT CustomerID, FullName, Email
FROM dbo.Customers
WHERE Email IS NOT NULL;

After executing the query above, I got the expected output as shown in the screenshot below.

You can combine tests. To find customers missing both email and phone:

SELECT CustomerID, FullName
FROM dbo.Customers
WHERE Email IS NULL
  AND Phone IS NULL;

After executing the query above, I got the expected output as shown in the screenshot below.

Only Eli matches. Use OR to find rows missing either one.

The Wrong Way: = NULL

-- Returns no rows: comparison with NULL is never true
SELECT * FROM dbo.Customers WHERE Email = NULL;

This runs without error but returns nothing. SQL Server has a legacy setting called ANSI_NULLS that changes this behavior, but turning it off is deprecated and risky because it makes your code behave differently from standard SQL. Always use IS NULL.

Pro Tip: I add a code review rule: any = NULL or <> NULL is rejected on sight. It has caught real bugs in reports that had been wrong for months.

Find Empty Strings and Fake NULLs Too

Real data is messy. Some systems store missing values as empty strings, spaces, or the text “NULL.” If you only search for real NULLs, you miss those. Check all three:

SELECT CustomerID, FullName, Email
FROM dbo.Customers
WHERE Email IS NULL
   OR LTRIM(RTRIM(Email)) = ''
   OR UPPER(LTRIM(RTRIM(Email))) = 'NULL';

This catches true NULLs, blank or whitespace-only values, and the literal text “NULL.” The function LTRIM(RTRIM(...)) removes spaces on both sides. The query now returns Ben, Cara, Dan, and Eli.

Another approach is NULLIF, which returns NULL when two values are equal. It turns blanks into NULLs for a quick test; see NULLIF vs. COALESCE.

SELECT CustomerID, FullName
FROM dbo.Customers
WHERE NULLIF(LTRIM(RTRIM(Email)), '') IS NULL;

This treats empty and whitespace-only emails as missing. Be aware that wrapping a column in functions stops SQL Server from using a normal index seek on that column, which matters on large tables. We cover that in the performance section.

Count NULLs in One Column or Across a Table

Counting reveals how serious a data quality problem is. COUNT(*) counts all rows, while COUNT(column) counts only non-NULL values. The difference is the NULL count. See the COUNT function.

SELECT
    COUNT(*)                          AS TotalRows,
    COUNT(Email)                      AS EmailsPresent,
    COUNT(*) - COUNT(Email)           AS EmailNulls,
    SUM(CASE WHEN Phone IS NULL THEN 1 ELSE 0 END)  AS PhoneNulls,
    SUM(CASE WHEN Region IS NULL THEN 1 ELSE 0 END) AS RegionNulls
FROM dbo.Customers;

With the sample data, there are 5 rows, 3 emails present (including the empty string and the text), 2 NULL emails, 2 NULL phones, and 2 NULL regions. The SUM(CASE ...) pattern counts rows that meet a condition. For more on CASE, see the CASE statement.

Check Every Nullable Column Automatically

On a table with 40 columns, typing each one is slow and error-prone. Use the system catalog to build the query. The sys.columns view lists each column and whether it allows NULL. To explore a table’s columns manually, see getting column names from a table and describing a table.

DECLARE @sql NVARCHAR(MAX);

SELECT @sql = N'SELECT COUNT(*) AS TotalRows, '
    + STRING_AGG(
        CAST(N'SUM(CASE WHEN ' + QUOTENAME(c.name) + N' IS NULL THEN 1 ELSE 0 END) AS '
             + QUOTENAME(c.name + N'_Nulls') AS NVARCHAR(MAX)),
        N', ')
    + N' FROM dbo.Customers;'
FROM sys.columns AS c
WHERE c.object_id = OBJECT_ID(N'dbo.Customers')
  AND c.is_nullable = 1;

EXEC sys.sp_executesql @sql;

Here is what happens:

• sys.columns returns one row per column, and is_nullable = 1 keeps only columns that can hold NULL. A NOT NULL column can never contain one, so counting it is wasteful.
• QUOTENAME wraps names in brackets and escapes special characters, which prevents broken SQL and SQL injection, an attack where untrusted text changes the query.
• STRING_AGG joins the generated pieces with commas. It requires SQL Server 2017 or later and is available in Azure SQL Database. The CAST to NVARCHAR(MAX) prevents truncation on wide tables.
• sp_executesql runs the generated statement. This is dynamic SQL, which builds a statement as text at run time; see dynamic SQL for the risks and benefits.

Replace dbo.Customers with your own table. For a variable table name, validate it against sys.tables first and never concatenate raw user input.

To find which tables contain a column you care about before you scan, see finding a table by column name and checking if a column exists.

Pro Tip: I run this catalog-driven count on every new data source before I trust it. A column that is 90 percent NULL usually means a broken import, not a real business fact.

Handle NULLs in Results and Joins

Finding NULLs is half the job. The other half is stopping them from breaking your logic.

Replace NULLs in output. Use ISNULL, which takes two arguments, or COALESCE, which accepts a list and returns the first non-NULL. See ISNULL and COALESCE.

SELECT FullName,
       COALESCE(Email, '(no email)') AS ContactEmail,
       IIF(Phone IS NULL, 'Missing', 'On file') AS PhoneStatus
FROM dbo.Customers;

COALESCE is standard SQL and works with more than two values. ISNULL is T-SQL specific and takes the data type of the first argument, which can silently truncate a longer replacement. For simple branching, IIF is a short form of CASE; see the IIF function.

Watch out for NOT IN. If a subquery returns even one NULL, NOT IN returns no rows at all, because the comparison with NULL is unknown.

-- Dangerous if the subquery can return NULL
SELECT CustomerID FROM dbo.Customers
WHERE CustomerID NOT IN (SELECT CustomerID FROM dbo.Orders);

Use NOT EXISTS or a left join with IS NULL instead. With a left join, which keeps every row from the left table, unmatched right-side columns come back as NULL; see SQL LEFT JOIN.

SELECT c.CustomerID, c.FullName
FROM dbo.Customers AS c
LEFT JOIN dbo.Orders AS o ON o.CustomerID = c.CustomerID
WHERE o.OrderID IS NULL;

This finds customers with no orders. Test for NULL on the right table’s key column, which is never NULL for a real match. Also remember that two NULLs are not equal in a join condition, so rows with NULL join keys never match.

Aggregates ignore NULLs. AVG, SUM, and COUNT(column) skip them. An average over a column that is half NULL covers only the known values, which may mislead readers.

Pro Tip: I once debugged a revenue report where NOT IN quietly returned an empty list after a single NULL appeared in a lookup table. Since then I default to NOT EXISTS.

Fix the Data: Defaults, Constraints, and Cleanup

Once you know where the NULLs are, decide whether they belong. A constraint is a rule SQL Server enforces on data; see SQL constraints. If a column should always have a value, make it NOT NULL, but clean the data first or the change will fail. Read how to change a column to NOT NULL.

Warning: the update below overwrites data. Back up first, run it in a transaction, and check the row count. See table backup in SQL Server.

-- Preview what will change
SELECT CustomerID, Region
FROM dbo.Customers
WHERE Region IS NULL;

BEGIN TRANSACTION;

UPDATE dbo.Customers
SET Region = 'Unknown'
WHERE Region IS NULL;

SELECT @@ROWCOUNT AS RowsUpdated;

-- COMMIT TRANSACTION;  -- run after you verify the count
-- ROLLBACK TRANSACTION; -- or undo

The preview SELECT uses the same WHERE clause, so you see exactly which rows will change. @@ROWCOUNT shows how many rows the last statement affected. Leaving the transaction open holds locks, so commit or roll back promptly.

Replacing NULL with a made-up value like ‘Unknown’ is a design choice. Sometimes NULL is the honest answer, and a placeholder can distort counts and averages. Decide with the business owner, and document the rule.

For broader design guidance, see SQL database design best practices.

Make NULL Searches Fast

A search for NULLs is only slow if SQL Server must read every row. Two habits help.

Keep the column bare. This query is sargable, meaning SQL Server can use an index seek:

WHERE LastOrderDate IS NULL

This one is not, because the function hides the column from the index:

WHERE ISNULL(LastOrderDate, '1900-01-01') = '1900-01-01'

Use a filtered index if you often search for rare NULLs. A filtered index covers only rows that meet a condition, so it stays small. See how to create an index in SQL Server.

CREATE NONCLUSTERED INDEX IX_Customers_NoEmail
ON dbo.Customers (CustomerID)
WHERE Email IS NULL;

This index lists only customers with no email, which suits a recurring “fix missing emails” report. The trade-off is extra storage and a small write cost. If NULLs are common, such as half the table, an index on them rarely helps. Check the actual execution plan first, and keep statistics fresh; see updating statistics on a table.

Pro Tip: In my experience, nobody notices a missing index on a NULL check until the report grows from thousands of rows to millions. I test NULL queries on a table copy sized like production.

NULL Audit Checklist

• Use IS NULL, never = NULL. Comparisons with NULL are never true.
• Look beyond real NULLs. Check for empty strings, spaces, and placeholder text such as “NULL.”
• Count per column. Use COUNT(*) - COUNT(column) or SUM(CASE ...), and generate queries from sys.columns for wide tables.
• Avoid NOT IN with nullable subqueries. Prefer NOT EXISTS or a left join.
• Back up before cleanup. Preview, use a transaction, and check @@ROWCOUNT.
• Limit access. Give audit jobs SELECT through an Entra identity over encrypted connections.

Frequently Asked Questions

How do I find NULL values in a SQL Server table?

Use WHERE column_name IS NULL. To find rows that have a value, use IS NOT NULL. Do not use = NULL, because it never returns rows.

How do I count NULL values in a column?

Use COUNT(*) - COUNT(column_name) or SUM(CASE WHEN column_name IS NULL THEN 1 ELSE 0 END). COUNT(column_name) skips NULLs, so the difference is the NULL count.

Why does WHERE column = NULL return no rows?

NULL means unknown, so any normal comparison with it evaluates to unknown, not true. SQL Server only returns rows where the condition is true. Use IS NULL instead.

How do I find all columns that contain NULLs?

Query sys.columns for nullable columns, then build a SUM(CASE WHEN ... IS NULL ...) expression for each with STRING_AGG and run it through sp_executesql. Use QUOTENAME for safety.

What is the difference between NULL and an empty string?

NULL means no value is known, while an empty string is a known value with zero length. They behave differently in comparisons and aggregates, so search for both when cleaning data.

You learned how to find null values in a table in SQL Server with IS NULL, count them per column, catch empty and fake NULLs, and handle them safely in joins and updates. Always preview with a SELECT, back up before changing data, and give audit jobs read-only access through an Entra identity. I hope you found this article helpful.

You May Also Like

• How to find duplicate records in SQL
• SQL normalization explained
• SQL DISTINCT
• SQL Server table naming conventions
• Primary key in SQL Server

That request is a classic problem: how to find consecutive dates in SQL. The good news is that SQL Server has a clean, fast pattern for it, and it needs no loops and no stack of self joins. This guide builds that pattern step by step with T-SQL, then shows how to find streak lengths, longest and current streaks, and missing dates, and how to index the table.

Build a Practice Table

A schema is the structure of your tables. Use a simple login log, the kind found in SaaS apps and audit trails.

CREATE TABLE dbo.UserLogins (
    LoginID INT IDENTITY(1,1) PRIMARY KEY,
    UserID  INT NOT NULL,
    LoginAt DATETIME2(0) NOT NULL
);

INSERT INTO dbo.UserLogins (UserID, LoginAt)
VALUES
 (1, '2026-10-01 09:10'), (1, '2026-10-02 08:05'), (1, '2026-10-02 17:45'),
 (1, '2026-10-03 10:30'), (1, '2026-10-05 11:00'), (1, '2026-10-06 12:15'),
 (1, '2026-10-09 07:50'),
 (2, '2026-10-01 14:00'), (2, '2026-10-03 13:20'), (2, '2026-10-04 09:40'),
 (2, '2026-10-05 16:10'), (2, '2026-10-06 08:30'), (2, '2026-10-07 10:05');

After running the query above, I got the expected output shown in the screenshot below.

Run this only in a test database. User 1 has two logins on October 2, which is a deliberate trap. Expected streaks are:

The LoginAt column stores a date and time. Consecutive-date logic works on dates, so you must remove the time part first. See SQL Server date data types and converting datetime to date.

Pro Tip: In my experience, every streak bug I have fixed involved a date the developer never tested: two events on the same day, a gap over a weekend, or a time component hiding in the column. I put all three in my test data before writing any query.

The Core Pattern: Date Minus Row Number

This technique is part of what DBAs call gaps and islands: an island is an unbroken run of values, and a gap is a break between islands. The trick is simple. If dates are consecutive and you subtract an increasing row number from each date, every date in the same streak produces the same result.

Oct 1 to Oct 3 all land on Sep 30, so they form one group. The jump to Oct 5 produces a new value, which starts a new group. That result becomes your grouping key.

WITH DistinctDays AS (
    SELECT DISTINCT
        UserID,
        CAST(LoginAt AS DATE) AS LoginDate
    FROM dbo.UserLogins
),
Numbered AS (
    SELECT
        UserID,
        LoginDate,
        DATEADD(DAY,
                -ROW_NUMBER() OVER (PARTITION BY UserID ORDER BY LoginDate),
                LoginDate) AS GroupKey
    FROM DistinctDays
)
SELECT
    UserID,
    MIN(LoginDate) AS StreakStart,
    MAX(LoginDate) AS StreakEnd,
    COUNT(*)       AS DaysInStreak
FROM Numbered
GROUP BY UserID, GroupKey
ORDER BY UserID, StreakStart;

Here is what each part does:

• DISTINCT with CAST(... AS DATE) keeps one row per user per day. Without it, user 1’s two logins on October 2 would break the pattern, because the row number would advance twice for one date. See DISTINCT.
• ROW_NUMBER() OVER (PARTITION BY ...) numbers each user’s dates from 1 upward. PARTITION BY restarts the numbering for each user; read ROW_NUMBER, PARTITION BY, and the OVER clause.
• DATEADD(DAY, -n, date) subtracts the row number from the date. See DATEADD.
• GROUP BY UserID, GroupKey collapses each island into one row, with its start, end, and length.

After running the query above, I got the expected output shown in the screenshot below.

A CTE (common table expression) is a named, temporary result that the next query can use. If you wonder when to use one instead of a temp table, see CTE vs. temp table.

The result matches the table above. This pattern reads the data once, sorts it once per user, and scales much better than repeated self joins.

Pro Tip: I always run the Numbered CTE by itself first and look at the GroupKey column. If the keys in one visible streak are not identical, the date cleanup is wrong, and every later step will be wrong too.

How to Find Users With a Minimum Streak

The original request was “five days in a row.” Add HAVING to filter the grouped islands. Read about HAVING vs. WHERE if you need a refresher.

WITH DistinctDays AS (
    SELECT DISTINCT UserID, CAST(LoginAt AS DATE) AS LoginDate
    FROM dbo.UserLogins
),
Numbered AS (
    SELECT UserID, LoginDate,
           DATEADD(DAY,
                   -ROW_NUMBER() OVER (PARTITION BY UserID ORDER BY LoginDate),
                   LoginDate) AS GroupKey
    FROM DistinctDays
)
SELECT UserID, MIN(LoginDate) AS StreakStart, MAX(LoginDate) AS StreakEnd,
       COUNT(*) AS DaysInStreak
FROM Numbered
GROUP BY UserID, GroupKey
HAVING COUNT(*) >= 5;

After running the query above, I got the expected output shown in the screenshot below.

With the sample data, only user 2 qualifies, with a five-day streak from October 3 to October 7. Change the number in HAVING for any threshold. A user can appear more than once if they had several qualifying streaks, so use SELECT DISTINCT UserID if the business only wants a list of users.

Find Each User’s Longest Streak

To keep only the best streak per user, rank the islands:

WITH DistinctDays AS (
    SELECT DISTINCT UserID, CAST(LoginAt AS DATE) AS LoginDate
    FROM dbo.UserLogins
),
Numbered AS (
    SELECT UserID, LoginDate,
           DATEADD(DAY,
                   -ROW_NUMBER() OVER (PARTITION BY UserID ORDER BY LoginDate),
                   LoginDate) AS GroupKey
    FROM DistinctDays
),
Streaks AS (
    SELECT UserID, MIN(LoginDate) AS StreakStart, MAX(LoginDate) AS StreakEnd,
           COUNT(*) AS DaysInStreak
    FROM Numbered
    GROUP BY UserID, GroupKey
),
Ranked AS (
    SELECT *,
           ROW_NUMBER() OVER (PARTITION BY UserID
                              ORDER BY DaysInStreak DESC, StreakEnd DESC) AS rn
    FROM Streaks
)
SELECT UserID, StreakStart, StreakEnd, DaysInStreak
FROM Ranked
WHERE rn = 1;

After running the query above, I got the expected output shown in the screenshot below.

The tie-breaker StreakEnd DESC makes the result stable when two streaks have the same length: the most recent one wins. User 1 returns Oct 1 to Oct 3, and user 2 returns Oct 3 to Oct 7.

Pro Tip: In my experience, stakeholders change the rule from “5 in a row” to “longest streak” to “current streak” in the same meeting. I build the Streaks CTE once and reuse it for all three questions.

Find the Current Streak

A “current streak” is one that includes today, or yesterday if today’s activity has not happened yet. Use a variable for the as-of date so you can test repeatably. For more on working with today’s date, see getting the days between a date and today.

DECLARE @AsOf DATE = '2026-10-09';  -- use CAST(GETDATE() AS DATE) in production

WITH DistinctDays AS (
    SELECT DISTINCT UserID, CAST(LoginAt AS DATE) AS LoginDate
    FROM dbo.UserLogins
),
Numbered AS (
    SELECT UserID, LoginDate,
           DATEADD(DAY,
                   -ROW_NUMBER() OVER (PARTITION BY UserID ORDER BY LoginDate),
                   LoginDate) AS GroupKey
    FROM DistinctDays
)
SELECT UserID, MIN(LoginDate) AS StreakStart, MAX(LoginDate) AS StreakEnd,
       COUNT(*) AS DaysInStreak
FROM Numbered
GROUP BY UserID, GroupKey
HAVING MAX(LoginDate) >= DATEADD(DAY, -1, @AsOf);

After running the query above, I got the expected output shown in the screenshot below.

This keeps streaks that ended today or yesterday. With the sample data and an as-of date of October 9, user 1’s one-day streak qualifies. Passing the date as a parameter also makes the logic easy to unit test. Time zones matter here: if your users are in several zones, decide whether “a day” is based on UTC or on the user’s local time, and store the rule in the query.

An Alternative: LAG to Flag Streak Breaks

The row-number trick is compact but a little abstract. The LAG approach is easier to explain to teammates. LAG reads a value from the previous row. See window functions in SQL Server.

WITH DistinctDays AS (
    SELECT DISTINCT UserID, CAST(LoginAt AS DATE) AS LoginDate
    FROM dbo.UserLogins
),
Flagged AS (
    SELECT UserID, LoginDate,
           CASE WHEN DATEDIFF(DAY,
                     LAG(LoginDate) OVER (PARTITION BY UserID ORDER BY LoginDate),
                     LoginDate) = 1
                THEN 0 ELSE 1 END AS IsNewStreak
    FROM DistinctDays
),
Grouped AS (
    SELECT UserID, LoginDate,
           SUM(IsNewStreak) OVER (PARTITION BY UserID ORDER BY LoginDate
                                  ROWS UNBOUNDED PRECEDING) AS StreakID
    FROM Flagged
)
SELECT UserID, StreakID,
       MIN(LoginDate) AS StreakStart,
       MAX(LoginDate) AS StreakEnd,
       COUNT(*) AS DaysInStreak
FROM Grouped
GROUP BY UserID, StreakID
ORDER BY UserID, StreakStart;

After running the query above, I got the expected output shown in the screenshot below.

The logic reads like a sentence. If the gap from the previous date is exactly one day, this row continues the streak, so the flag is 0. Otherwise it starts a new streak, so the flag is 1. For the first row, LAG returns NULL, DATEDIFF returns NULL, the comparison is not true, and the flag becomes 1, which is correct. A running SUM of the flags then gives each streak an ID. See DATEDIFF for how it counts boundaries.

Both approaches give the same answer. The row-number version needs one window function; the LAG version needs two, but each step is easier to debug. Pick the one your team can maintain.

Pro Tip: I use the LAG version when I am teaching or handing the query to someone new, and the date-minus-row-number version when I want the shortest code. Whichever you choose, add a comment explaining why it works.

Find Missing Dates (Gaps)

The opposite question is just as common: when did a user skip days? Use LEAD, which reads the next row’s value.

WITH DistinctDays AS (
    SELECT DISTINCT UserID, CAST(LoginAt AS DATE) AS LoginDate
    FROM dbo.UserLogins
),
WithNext AS (
    SELECT UserID, LoginDate,
           LEAD(LoginDate) OVER (PARTITION BY UserID ORDER BY LoginDate) AS NextDate
    FROM DistinctDays
)
SELECT UserID,
       DATEADD(DAY, 1, LoginDate)  AS GapStart,
       DATEADD(DAY, -1, NextDate)  AS GapEnd,
       DATEDIFF(DAY, LoginDate, NextDate) - 1 AS MissingDays
FROM WithNext
WHERE DATEDIFF(DAY, LoginDate, NextDate) > 1
ORDER BY UserID, GapStart;

After running the query above, I got the expected output shown in the screenshot below.

For user 1, this returns Oct 4 (1 day) and Oct 7 to Oct 8 (2 days). The final row for each user has no next date, so DATEDIFF is NULL and the row is filtered out, which is the behavior you want. These gap reports help with churn detection, missing sensor readings, and compliance checks.

Why Self Joins Are the Wrong Tool

You may see answers like this:

SELECT a.UserID, a.LoginDate
FROM DistinctDays a
JOIN DistinctDays b ON b.UserID = a.UserID AND b.LoginDate = DATEADD(DAY, 1, a.LoginDate)
JOIN DistinctDays c ON c.UserID = a.UserID AND c.LoginDate = DATEADD(DAY, 2, a.LoginDate);

It finds three-day streaks, but it has serious problems. You need one extra join per day of the streak, so a seven-day rule needs seven joins. It returns overlapping rows for longer streaks, so a ten-day streak is reported several times. And performance falls as the table grows. See joins in SQL Server for when self joins are the right tool. For streaks of any length, the window approach is almost always better.

Loops are also a poor fit. A row-by-row WHILE loop processes one date at a time, which is slow and hard to read; set-based T-SQL does the same job in one pass.

Make It Fast: Indexing and Date Types

A clustered index defines how rows are physically stored, and a nonclustered index is a separate sorted structure that speeds up lookups. The streak query partitions by user and sorts by date. An index that already has that order lets SQL Server skip an expensive sort. See how to create an index in SQL Server.

Because the query casts LoginAt to a date, you can store the date part in a persisted computed column, a column calculated from others and stored physically so it can be indexed.

ALTER TABLE dbo.UserLogins
ADD LoginDate AS CAST(LoginAt AS DATE) PERSISTED;

CREATE NONCLUSTERED INDEX IX_UserLogins_User_LoginDate
ON dbo.UserLogins (UserID, LoginDate);

Test this on a non-production copy first. Adding a persisted column to a large table can take time and locks. The index supports PARTITION BY UserID ORDER BY LoginDate and lets SQL Server read each user’s dates in order. The trade-off is extra storage and slightly slower inserts, because every new login updates the index.

Other tuning tips:

• Filter by a date range first. If you only need the last 90 days, add a range such as LoginAt >= @Start AND LoginAt < @End so the engine reads less. See filtering by date and SQL query optimization tips.
• Pre-aggregate large logs. For hundreds of millions of rows, keep a small daily table with one row per user per day, updated by a nightly job, and run streak queries against that.
• Check the actual execution plan for Sort operators and scans. In Azure SQL Database, use Query Store to compare run time before and after the index.Pro Tip: In my experience, a daily summary table beats any clever index once the log gets huge. It turns “scan every login ever” into “read one row per user per day.”

Frequently Asked Questions

How do I find consecutive dates in SQL Server?

Remove duplicate days, number each user’s dates with ROW_NUMBER(), and subtract that number from the date. Dates in the same streak give the same result, so you can group by it. Then use MIN, MAX, and COUNT to get the start, end, and length.

How do I find users who logged in three days in a row?

Use the grouping pattern and add HAVING COUNT(*) >= 3. Apply DISTINCT UserID if you only need a list of users instead of each streak.

What is the difference between ROW_NUMBER and LAG for streaks?

ROW_NUMBER with date subtraction creates the group key in one step and is shorter. LAG compares each date to the previous one, flags breaks, and builds groups with a running sum; it is longer but easier to read and debug.

How do I find missing dates between rows?

Use LEAD to get each row’s next date, then keep rows where DATEDIFF(DAY, LoginDate, NextDate) > 1. The gap runs from one day after the current date to one day before the next date.

Why does my streak query miscount when users log in twice a day?

Duplicate rows advance ROW_NUMBER without advancing the date, which breaks the pattern. Select DISTINCT UserID, CAST(LoginAt AS DATE) first so each day counts once.

You learned how to find consecutive dates in SQL Server by cleaning dates, numbering rows, grouping streaks, and using LAG and LEAD for flags and gaps. Always reduce your data to one row per entity per day before applying streak logic, and give report users read-only access to a view instead of the raw log. I hope you found this article helpful.

You May Also Like

• How to find the maximum date in SQL Server
• How to find the minimum date in SQL Server
• How to add days to a date in SQL Server
• How to get the weekday from a date in SQL Server
• How to get the latest record by date in SQL Server
• How to Find NULL Values in a Table in SQL Server

That bug is why choosing how to generate sequence number in SQL Server matters more than it looks. SQL Server gives you four solid options: IDENTITY columns, SEQUENCE objects, ROW_NUMBER() for query results, and a counter table for business-specific numbering. Each fits a different job. This guide shows them with T-SQL, explains gaps and concurrency, and covers permissions and testing in SQL Server and Azure SQL Database, so you can pick the right tool and avoid the Black Friday bug.

Choose the Right Method First

Different needs call for different tools. A sequence number here means an ordered number generated by the database, either stored in a table or created in a query result.

Start with the first question: does the number need to be stored, or only displayed? A stored number needs IDENTITY, SEQUENCE, or a counter table. A displayed number almost always needs ROW_NUMBER().

Pro Tip: In my experience, most sequence problems come from using a stored-number tool for a display-number job, or the reverse. I write one sentence first: “This number must be .” Unique, ordered, gap-free, or per-customer. The answer picks the tool.

Method 1: Use IDENTITY for Automatic Row IDs

An identity column is a column where SQL Server generates the next value automatically for each new row. It is the simplest and most common choice. If you need a refresher, see how to create an identity column in SQL Server and creating a table with an identity column.

CREATE TABLE dbo.Orders (
    OrderID     INT IDENTITY(1,1) PRIMARY KEY,
    CustomerID  INT NOT NULL,
    OrderDate   DATETIME2(0) NOT NULL DEFAULT SYSUTCDATETIME()
);

INSERT INTO dbo.Orders (CustomerID) VALUES (101), (102), (103);

After running the query above, I got the expected output shown in the screenshot below.

IDENTITY(1,1) means the first value is 1 and each new row adds 1. You do not insert a value for OrderID; SQL Server supplies it. The primary key makes the column unique and creates a clustered index by default, which is the sorted structure that stores the table’s rows. New identity values are always increasing, so inserts append to the end of the index, which keeps page splits low.

To get the value that was just created in your session, use SCOPE_IDENTITY():

INSERT INTO dbo.Orders (CustomerID) VALUES (104);
SELECT SCOPE_IDENTITY() AS NewOrderID;

After running the query above, I got the expected output shown in the screenshot below.

Prefer SCOPE_IDENTITY() over @@IDENTITY, because @@IDENTITY can return a value generated by a trigger on another table. Read more in SCOPE_IDENTITY in SQL Server.

Identity Gaps Are Normal

Identity values are not gap-free. A rolled-back transaction still consumes a value. A failed insert consumes one too. After some unexpected restarts, SQL Server can skip a block of values because it caches identity numbers in memory. Treat identity as “unique and increasing,” not “consecutive.”

If you absolutely need to insert your own value, such as during a data migration, you must turn on IDENTITY_INSERT for that table; see SET IDENTITY_INSERT. If you forget, you get the error described in cannot insert explicit value for identity column. To reset the counter, see how to reset an identity column.

Warning: reseeding to a value that already exists can cause primary key violations later.

Pro Tip: I once saw a developer reseed an identity to 0 on a table that still had rows. Everything worked until the counter reached an existing ID, then inserts started failing at random. I now only reseed after confirming the table is empty or the new seed is above the maximum.

Method 2: Use a SEQUENCE Object for Shared or Pre-Generated Numbers

A sequence is a database object, separate from any table, that hands out numbers. Use it when several tables need numbers from one series, when the app needs the number before inserting, or when you want a number on a column that cannot be an identity.

Sequences are supported in SQL Server 2012 and later, and in Azure SQL Database and Azure SQL Managed Instance.

CREATE SEQUENCE dbo.OrderNumberSeq
    AS BIGINT
    START WITH 100000
    INCREMENT BY 1
    MINVALUE 100000
    NO CYCLE
    CACHE 50;

After running the query above, I got the expected output shown in the screenshot below.

This creates a sequence of BIGINT values starting at 100000. NO CYCLE means SQL Server raises an error at the maximum value instead of starting over, which prevents silent duplicates. CACHE 50 keeps 50 values in memory so SQL Server does not write to disk for every number.

The trade-off is that a crash or restart can skip up to the cached amount. If you need fewer gaps, use NO CACHE, at some cost in speed.

Attach it to a column with a default constraint:

ALTER TABLE dbo.Orders
ADD OrderNumber BIGINT NOT NULL
    CONSTRAINT DF_Orders_OrderNumber
    DEFAULT (NEXT VALUE FOR dbo.OrderNumberSeq),
    CONSTRAINT UQ_Orders_OrderNumber UNIQUE (OrderNumber);

After running the query above, I got the expected output shown in the screenshot below.

NEXT VALUE FOR pulls the next number. The UNIQUE constraint is important: a sequence does not enforce uniqueness by itself, because someone can still insert a manual value. The constraint closes that hole. Note that adding a NOT NULL column with a default to a large table can take time and locks, so test it first.

You can also request a number manually:

DECLARE @n BIGINT = NEXT VALUE FOR dbo.OrderNumberSeq;
SELECT @n AS ReservedNumber;

After running the query above, I got the expected output shown in the screenshot below.

This is useful when the app must show or log the number before the row is saved. Be aware that if the transaction later fails, that number is used up. Sequences, like identity, can have gaps.

For bulk loads, reserve a block at once with sp_sequence_get_range, which returns a start and end for the block. That is much faster than asking one row at a time.

IDENTITY vs. SEQUENCE

Pro Tip: In my experience, teams reach for sequences too early. I use IDENTITY by default and switch to a sequence only when I need a shared series or the number before the insert.

Method 3: Use ROW_NUMBER() to Number Query Results

Sometimes you only need numbering in a result, such as a ranked leaderboard or a paged list. ROW_NUMBER() is a window function, a function that calculates across a set of rows without collapsing them. See ROW_NUMBER in SQL Server and the OVER clause.

SELECT
    ROW_NUMBER() OVER (ORDER BY OrderDate, OrderID) AS RowNum,
    OrderID,
    CustomerID,
    OrderDate
FROM dbo.Orders;

After running the query above, I got the expected output shown in the screenshot below.

The ORDER BY inside OVER sets the numbering order. Always add a tie-breaker, such as OrderID, so the numbers are stable when two rows share a date.

To restart the numbering for each customer, add PARTITION BY; see PARTITION BY.

SELECT
    CustomerID,
    OrderID,
    ROW_NUMBER() OVER (
        PARTITION BY CustomerID
        ORDER BY OrderDate, OrderID) AS CustomerOrderNo
FROM dbo.Orders;

After running the query above, I got the expected output shown in the screenshot below.

Each customer’s orders are numbered 1, 2, 3, and so on. The number exists only in the result. If you save it into a table, it will not update when rows are added or deleted.

A common use is deduplication and “latest row” queries, where ROW_NUMBER() = 1 picks one row per group. It is also faster than old tricks that used a self join or correlated subquery.

Pro Tip: In my experience, a window function on a large unindexed sort is where reports slow down. Before I tune anything, I check the execution plan for a Sort operator, then consider an index that matches the PARTITION BY and ORDER BY columns.

Method 4: Build Business Numbers With a Counter Table

Invoices often need numbers that are consecutive and reset per tenant or per year, such as INV-2026-000124. Identity and sequences allow gaps, and neither restarts per tenant. For gap-free or per-tenant numbers, use a small counter table and update it inside the same transaction as the insert.

CREATE TABLE dbo.InvoiceCounters (
    TenantID   INT NOT NULL,
    YearNo     INT NOT NULL,
    LastNumber INT NOT NULL,
    CONSTRAINT PK_InvoiceCounters PRIMARY KEY (TenantID, YearNo)
);

INSERT INTO dbo.InvoiceCounters VALUES (1, 2026, 0);

After running the query above, I got the expected output shown in the screenshot below.

Then increment and read the value in one atomic statement:

DECLARE @TenantID INT = 1, @YearNo INT = 2026, @n INT;

BEGIN TRANSACTION;

UPDATE dbo.InvoiceCounters
SET @n = LastNumber = LastNumber + 1
WHERE TenantID = @TenantID AND YearNo = @YearNo;

SELECT CONCAT('INV-', @YearNo, '-', RIGHT(CONCAT('000000', @n), 6)) AS InvoiceNumber;

COMMIT TRANSACTION;

After running the query above, I got the expected output shown in the screenshot below.

The statement SET @n = LastNumber = LastNumber + 1 updates the row and captures the new value in a single step. SQL Server takes an update lock on that row, so a second session waits until the first transaction commits.

That serialization is what prevents duplicates and gaps. It also means invoice creation for the same tenant is serialized, which is a throughput limit. Keep the transaction short, and put the counter update as late in the transaction as possible.

If the transaction rolls back, the counter update rolls back too, so no number is lost. The RIGHT(CONCAT('000000', @n), 6) expression pads with leading zeros; for other ways, see converting an integer to a string with leading zeros. Wrap this logic in a stored procedure so every app uses the same code; see creating a stored procedure.

Under heavy load, long transactions here can cause blocking, where one session waits on another’s locks, and in the worst case a deadlock, where two sessions wait on each other. Read about deadlock victims and keep the update order consistent in every procedure.

Pro Tip: I once saw an invoice procedure hold the counter lock while it called a slow tax service. Invoice creation backed up for minutes. Now I do slow calls first and update the counter last, right before the commit.

Generate a Simple List of Numbers

To create a list such as 1 to 100, use GENERATE_SERIES, available in SQL Server 2022 and Azure SQL Database.

SELECT value AS Number
FROM GENERATE_SERIES(1, 100);

Add a third argument for the step, as in GENERATE_SERIES(10, 100, 10). For older versions, a recursive CTE works but is slower and limited by MAXRECURSION. Avoid row-by-row loops to build numbers; a set-based approach is almost always faster than a WHILE loop. If you do need a loop, see WHILE loops in stored procedures.

Number lists are handy for date tables and test data. To load them into another table, use INSERT INTO … SELECT.

Never Use MAX + 1

The pattern that broke the Black Friday orders looks like this:

-- Unsafe under concurrency: do not use
DECLARE @next INT = (SELECT MAX(OrderNumber) + 1 FROM dbo.Orders);
INSERT INTO dbo.Orders (OrderNumber, CustomerID) VALUES (@next, 101);

Two sessions can both read the same maximum before either inserts. Locking hints can make it safer, but they add complexity and blocking, and a tool built for the job is simpler. Use IDENTITY, a SEQUENCE, or the counter table. If you want to review how MAX works, see the MAX function.

Frequently Asked Questions

How do I generate a sequence number in SQL Server?

Use an IDENTITY column for automatic row numbers, a SEQUENCE object with NEXT VALUE FOR for shared or pre-assigned numbers, or ROW_NUMBER() to number query results. The best choice depends on whether the number is stored or only displayed.

What is the difference between IDENTITY and SEQUENCE?

IDENTITY belongs to one table and fills in automatically. A SEQUENCE is a separate object that multiple tables can use, and you can fetch its value before inserting. Both can have gaps.

Why does my identity column skip numbers?

Rolled-back transactions and failed inserts consume values, and cached values can be lost after a restart. Identity guarantees uniqueness and increasing order, not consecutive values.

How do I get gap-free invoice numbers in SQL Server?

Use a counter table updated inside the same transaction as the invoice insert, so a rollback also rolls back the number. Keep the transaction short, because this approach serializes writers for the same counter.

How do I restart row numbers for each group?

Use ROW_NUMBER() OVER (PARTITION BY group_column ORDER BY sort_column). Numbering restarts at 1 for each partition and exists only in the query result.

You learned four ways to generate sequence number values in SQL Server: IDENTITY, SEQUENCE, ROW_NUMBER(), and counter tables, and why each behaves differently with gaps and concurrency. Never calculate the next number with MAX + 1; let the database generate it, enforce uniqueness with a constraint, and test parallel inserts before you go live. I hope you found this article helpful.

You May Also Like

• How to insert an identity column in SQL Server
• How to add identity to an existing column in SQL Server
• How to create a table with a primary key in SQL Server
• How to add a primary key to an existing table
• How to truncate a table in SQL Server

That bug is why how to find even and odd numbers in SQL Server is a better question than it looks. The basic test is one operator. A production-safe version has to handle negatives, NULLs, decimals, text columns, and performance on large tables. This guide covers each case in T-SQL, shows how to generate and label number sequences, and explains how to keep these checks fast and safe in Azure SQL Database or SQL Server.

Create a Practice Table With Edge Cases

Test on a small table that includes the awkward values. A schema is the structure of your tables, and sample rows with edge cases reveal bugs early. If you need background on identity columns, see creating a table with an identity column.

CREATE TABLE dbo.StockAdjustments (
    AdjustmentID INT IDENTITY(1,1) PRIMARY KEY,
    SKU          VARCHAR(20) NOT NULL,
    QtyChange    INT NULL
);

INSERT INTO dbo.StockAdjustments (SKU, QtyChange)
VALUES
 ('A-100', 10),
 ('A-101', 7),
 ('A-102', -3),
 ('A-103', -8),
 ('A-104', 0),
 ('A-105', NULL),
 ('A-106', 15);

After executing the above query, I got the expected output as shown in the screenshot below.

The table has positive and negative numbers, zero, and a NULL. A NULL is a missing or unknown value, not zero. Run this only in a test database, because it inserts rows.

Pro Tip: In my experience, every number-logic bug I have fixed involved a value the developer never tested: zero, a negative, or NULL. I put all three in my sample data before writing the first query.

The Modulo Method to Find Even and Odd Numbers in SQL Server

The modulo operator (%) returns the remainder after division. Any even number divided by 2 leaves a remainder of 0. Any odd number leaves a remainder of 1 or, for negatives in SQL Server, -1.

SELECT AdjustmentID, QtyChange
FROM dbo.StockAdjustments
WHERE QtyChange % 2 = 0;

After executing the above query, I got the expected output as shown in the screenshot below.

This returns 10, -8, and 0. Zero is even, which is mathematically correct. The NULL row is not returned, because NULL % 2 is NULL, and a comparison with NULL is never true. Learn more in how SQL handles NULL and the WHERE clause tutorial.

The Negative Number Trap

Now try the obvious query for odd numbers:

-- Misses negative odd numbers
SELECT AdjustmentID, QtyChange
FROM dbo.StockAdjustments
WHERE QtyChange % 2 = 1;

After executing the above query, I got the expected output as shown in the screenshot below.

After executing the above query, I got the expected output as shown in the screenshot below.

This returns 7 and 15 but not -3. In SQL Server, the result of % takes the sign of the dividend, so -3 % 2 equals -1, not 1. The fix is to test for “not even” instead:

SELECT AdjustmentID, QtyChange
FROM dbo.StockAdjustments
WHERE QtyChange % 2 <> 0;

After executing the above query, I got the expected output as shown in the screenshot below.

Now the result is 7, -3, and 15. Using <> 0 works for positive and negative numbers. Alternatively, wrap the result in ABS(), which returns the absolute value, as in ABS(QtyChange % 2) = 1.

Pro Tip: I never write % 2 = 1 anymore. I use % 2 <> 0 for odd numbers, so negative values are handled without thinking about it.

Use CASE to Label Each Row

Often you need a label, not a filter. CASE evaluates conditions in order and returns the first match; see the CASE statement in SQL Server.

SELECT
    AdjustmentID,
    QtyChange,
    CASE
        WHEN QtyChange IS NULL THEN 'Unknown'
        WHEN QtyChange % 2 = 0 THEN 'Even'
        ELSE 'Odd'
    END AS Parity
FROM dbo.StockAdjustments;

The NULL check comes first so the row is labeled Unknown instead of falling into ELSE and being called odd. That mistake is common: any NULL that fails the even test would land in the odd bucket.

For a simple two-way choice, IIF is shorter; see the IIF function.

SELECT AdjustmentID,
       IIF(QtyChange % 2 = 0, 'Even', 'Odd') AS Parity
FROM dbo.StockAdjustments
WHERE QtyChange IS NOT NULL;

IIF is shorthand for a two-branch CASE. It cannot express an “Unknown” third case on its own, so filter NULLs out first, as above.

The Bitwise Method

A bitwise AND (&) compares the binary bits of two numbers. In binary, an odd number always has its last bit set to 1. So value & 1 returns 1 for odd numbers and 0 for even ones, including negatives, which SQL Server stores in two’s complement form.

SELECT AdjustmentID, QtyChange,
       QtyChange & 1 AS IsOdd
FROM dbo.StockAdjustments
WHERE QtyChange IS NOT NULL;

For -3, the result is 1, so the negative number is correctly seen as odd. This avoids the sign problem of %. The limits are that & works only on integer types, not DECIMAL, and many readers find % 2 clearer. I use bitwise checks in code where the data is always integer and I want one result for any sign, and % 2 <> 0 everywhere else.

Pro Tip: I keep the bitwise form out of shared code unless I add a comment. A teammate who does not recognize & 1 may “fix” it later, so I write -- 1 = odd beside it.

Decimals, Text Columns, and Data Types

The modulo operator accepts integer, money, and numeric types. It rejects FLOAT and REAL, and it does not make sense for fractions: 7.5 % 2 returns 1.5, which is neither 0 nor 1. If a column stores decimals, decide what “even” means first. Many teams round or cast to an integer, or reject non-whole values.

SELECT 7.5 % 2 AS DecimalRemainder,   -- 1.5
       CAST(8.0 AS INT) % 2 AS WholeValue;  -- 0

If the number is stored as text, convert it before testing. A data type tells SQL Server what kind of value a column holds. Use TRY_CONVERT, which returns NULL instead of an error when conversion fails; see TRY_CONVERT and the CAST function.

sqlSELECT Value,
       CASE
           WHEN TRY_CONVERT(INT, Value) IS NULL THEN 'Not a whole number'
           WHEN TRY_CONVERT(INT, Value) % 2 = 0 THEN 'Even'
           ELSE 'Odd'
       END AS Parity
FROM (VALUES ('12'), ('7'), ('abc'), ('3.5')) AS v(Value);

Without TRY_CONVERT, the text 'abc' would raise a conversion error; see the varchar to numeric conversion error. Storing numbers in text columns causes these problems repeatedly, so fix the data type if you control the schema.

Pro Tip: In my experience, “even or odd” bugs on imported data are usually text-cleanup bugs. Check with TRY_CONVERT first and fix the bad rows before the logic runs.

Count and Sum Even and Odd Values

Reports often need totals by parity. Combine GROUP BY with the parity test; see how COUNT works and the SUM function.

SELECT
    CASE WHEN QtyChange % 2 = 0 THEN 'Even' ELSE 'Odd' END AS Parity,
    COUNT(*)        AS Rows_,
    SUM(QtyChange)  AS TotalQty
FROM dbo.StockAdjustments
WHERE QtyChange IS NOT NULL
GROUP BY CASE WHEN QtyChange % 2 = 0 THEN 'Even' ELSE 'Odd' END;

With the sample data, even rows are 10, -8, and 0, with 3 rows and a total of 2. Odd rows are 7, -3, and 15, also 3 rows with a total of 19. The CASE expression appears in both SELECT and GROUP BY, because SQL Server needs the same expression in each.

Generate a List of Even and Odd Numbers

To produce a range of numbers, use GENERATE_SERIES, available in SQL Server 2022 and Azure SQL Database. It returns a sequence of numbers.

SELECT value AS EvenNumber
FROM GENERATE_SERIES(1, 20)
WHERE value % 2 = 0;

This returns 2, 4, 6, up to 20. Its second argument is the stop value, and an optional third argument sets the step. You can skip filtering by stepping directly: GENERATE_SERIES(2, 20, 2) returns only the even numbers, which is more efficient.

On older versions, use a recursive CTE (common table expression), a named temporary result you can query right away.

WITH Numbers AS (
    SELECT 1 AS n
    UNION ALL
    SELECT n + 1 FROM Numbers WHERE n < 20
)
SELECT n AS OddNumber
FROM Numbers
WHERE n % 2 <> 0
OPTION (MAXRECURSION 100);

MAXRECURSION sets a safety limit on how many times the CTE can call itself. The default is 100. Raise it deliberately for larger ranges, because it protects you from runaway loops. For more row-by-row logic, a loop is possible but slower; see WHILE loops in stored procedures. In my experience, set-based code like GENERATE_SERIES beats loops almost every time.

Frequently Asked Questions

How do I check if a number is even or odd in SQL Server?

Use the modulo operator. value % 2 = 0 means even, and value % 2 <> 0 means odd. The <> 0 form also works for negative numbers.

Why does % 2 = 1 miss some odd numbers?

In SQL Server, the sign of the result matches the sign of the dividend, so -3 % 2 returns -1. Test for <> 0 or use ABS(value % 2) = 1.

Is zero even or odd in SQL?

Zero is even, because 0 % 2 returns 0. Your query will classify it as even.

How do I get only even rows from a table?

If you mean rows at even positions, number them with ROW_NUMBER() and filter rn % 2 = 0. If you mean even ID values, filter ID % 2 = 0, but remember that gaps in an identity column make this different from alternating rows.

Can I use an index to speed up even and odd filters?

Not directly, because value % 2 is not sargable. A persisted computed column can be indexed, but a two-value column has low selectivity, so test the execution plan before adding it.

You learned how to find even and odd numbers in SQL Server with modulo, bitwise AND, CASE, GENERATE_SERIES, and ROW_NUMBER, and how to handle negatives, NULLs, and text values. Test your logic against zero, negative, and NULL values, and give report users read-only access through an Entra identity. I hope you found this article helpful.

You May Also Like

• How to Use CASE WHEN in SQL Server
• How to Generate Sequence Number in SQL Server (4 Ways)
• How to use the AVG function in SQL Server
• How to use the MAX function in SQL Server
• How to use the MIN function in SQL Server
• Top 10 SQL Server commands you must know
• SQL cheat sheet

That is the classic trap behind how to swap two column values in SQL. In many languages you need a temporary variable. In SQL Server you can often do it with a single statement, if you understand how UPDATE evaluates its values. You also need a safety plan, because a bad swap overwrites data in place. This guide shows the safe one-statement method, previews, rollback options, and what to check in Azure SQL Database or SQL Server before touching production.

Why a Swap Needs a Plan

Suppose you run two separate updates:

UPDATE dbo.Contacts SET FirstName = LastName;  -- dangerous
UPDATE dbo.Contacts SET LastName = FirstName;

After the first statement, FirstName already contains the last name, and the original first name is gone. The second statement copies the same value back. Both columns now hold the last name. This is permanent data loss unless you have a backup.

SQL Server avoids this problem when you do both assignments in one UPDATE. The reason is a behavior often called all-at-once evaluation: every expression on the right side of SET reads the row’s original values, before any column is changed. That makes a swap clean and atomic, meaning it either fully happens or does not happen.

Pro Tip: In my experience, the real risk is not the syntax. It is running a swap on the wrong rows. I always build the WHERE clause first, preview it with SELECT, and only then convert it to UPDATE.

Create a Practice Table

Work in a test database first. This example models the contact import problem. A schema is the structure of your tables, and a batch here means a group of rows loaded together.

CREATE TABLE dbo.Contacts (
    ContactID   INT IDENTITY(1,1) PRIMARY KEY,
    FirstName   VARCHAR(50) NOT NULL,
    LastName    VARCHAR(50) NOT NULL,
    ImportBatch INT NOT NULL
);

INSERT INTO dbo.Contacts (FirstName, LastName, ImportBatch)
VALUES
 ('Chen',    'Ava',   7),   -- reversed
 ('Ortiz',   'Ben',   7),   -- reversed
 ('Cara',    'Singh', 6),   -- correct
 ('Weber',   'Dan',   7),   -- reversed
 ('Eli',     'Brooks',6);   -- correct

Batch 7 contains the reversed names. Batches 6 and below are correct, which is why the filter matters. If you need a refresher on creating tables, see how to create a table in SSMS using a query.

After running the query above, I got the expected output shown in the screenshot below.

How to Swap Two Column Values in SQL with One UPDATE

Preview first. A SELECT costs nothing and changes nothing.

SELECT
    ContactID,
    FirstName AS CurrentFirst,
    LastName  AS CurrentLast,
    LastName  AS NewFirst,
    FirstName AS NewLast
FROM dbo.Contacts
WHERE ImportBatch = 7;

This shows what the data looks like now and what it will look like after the swap. Check a handful of rows by eye. Then run the update. Warning: this statement overwrites data.

After running the query above, I got the expected output shown in the screenshot below.

BEGIN TRANSACTION;

UPDATE dbo.Contacts
SET FirstName = LastName,
    LastName  = FirstName
WHERE ImportBatch = 7;

SELECT @@ROWCOUNT AS RowsSwapped;

Here is what each part does:

• BEGIN TRANSACTION starts a transaction, a unit of work you can undo until you commit.
• The SET list assigns each column the other’s original value. SQL Server evaluates both right-hand sides before writing.
• WHERE ImportBatch = 7 limits the change to bad rows. Learn more in the WHERE clause tutorial.
• @@ROWCOUNT returns how many rows the previous statement changed. Compare it with the count from your preview.

After running the query above, I got the expected output shown in the screenshot below.

If the count and sample rows look right, run COMMIT TRANSACTION;. If anything looks wrong, run ROLLBACK TRANSACTION; and the table returns to its previous state.

Leave the transaction open only briefly. An open transaction holds locks, which are protections that stop other sessions from changing the same rows. A long-running transaction can cause blocking, where other queries wait for your locks to be released.

Pro Tip: I once watched a developer leave a transaction open over lunch in SSMS. Every report that touched the table hung. I now run BEGIN TRANSACTION, check the row count, and commit or roll back right away.

Preserve the Old Values Before You Swap

A swap is easy to reverse if you know the original values, and impossible to reverse if you do not. Back up the affected rows first. You can create a copy of the table or just the rows you plan to change. See table backup in SQL Server and copying a table to another table.

SELECT ContactID, FirstName, LastName, ImportBatch
INTO dbo.Contacts_Backup_20261102
FROM dbo.Contacts
WHERE ImportBatch = 7;

After running the query above, I got the expected output shown in the screenshot below.

SELECT ... INTO creates a new table and copies the rows. It is a quick safety copy, though it does not copy indexes or constraints.

You can also record changes as they happen using the OUTPUT clause, which returns the old and new values from the same UPDATE.

CREATE TABLE dbo.Contacts_SwapLog (
    ContactID INT NOT NULL,
    OldFirst  VARCHAR(50) NOT NULL,
    OldLast   VARCHAR(50) NOT NULL,
    NewFirst  VARCHAR(50) NOT NULL,
    NewLast   VARCHAR(50) NOT NULL,
    ChangedAt DATETIME2(0) NOT NULL DEFAULT SYSUTCDATETIME()
);

UPDATE dbo.Contacts
SET FirstName = LastName,
    LastName  = FirstName
OUTPUT inserted.ContactID,
       deleted.FirstName, deleted.LastName,
       inserted.FirstName, inserted.LastName
INTO dbo.Contacts_SwapLog (ContactID, OldFirst, OldLast, NewFirst, NewLast)
WHERE ImportBatch = 7;

After running the query above, I got the expected output shown in the screenshot below.

In OUTPUT, deleted holds the row values before the change and inserted holds them after. This gives you an audit trail with no extra queries. If someone later asks what changed, you have the answer.

Pro Tip: In my experience, an OUTPUT ... INTO log table takes two minutes to write and has saved me hours. It also gives auditors a clear record of who changed what and when.

Swap Columns With Different Data Types or Constraints

The one-statement swap is simple when both columns are the same type. Real tables are messier.

Mismatched Data Types

If one column is INT and the other is VARCHAR, SQL Server must convert values. Conversion can fail on non-numeric text. Use explicit conversion and test it before updating. See the CAST function and TRY_CONVERT, which returns NULL instead of an error. If you hit a failure, read about the varchar to numeric conversion error.

-- Find rows that would fail before you update anything
SELECT ContactID, FirstName
FROM dbo.Contacts
WHERE TRY_CONVERT(INT, FirstName) IS NULL;

After running the query above, I got the expected output shown in the screenshot below.

Different Lengths

If one column is VARCHAR(20) and the other is VARCHAR(100), moving a long value into the short column fails. SQL Server raises a truncation error; see string or binary data would be truncated. Check the longest value first with MAX(LEN(column)).

NOT NULL and CHECK Constraints

A constraint is a rule that SQL Server enforces on data. If one column allows NULL and the other does not, swapping a NULL into the NOT NULL column fails. A CHECK constraint can also block a swap. For example, a shipment table might require DeliveryDate >= PickupDate. If the dates were reversed by mistake, swapping them fixes the data, but swapping correct rows would break the rule. Read more in SQL constraints.

Triggers

A trigger is code that runs automatically when data changes. An update trigger will fire during your swap and may write audit rows, send events, or block the change. Know what exists before you update. Review triggers in SQL Server.

Pro Tip: I always check for triggers and check constraints on the table before a bulk change. Finding out halfway through a production update is a bad time to learn that a trigger sends an email per row.

Conditional Swaps and Large Tables

Sometimes you only want to swap when a rule is true. For example, swap only when the “first name” looks like it belongs in the last name column. Use CASE, which returns different values depending on conditions. See the CASE statement.

UPDATE dbo.Contacts
SET FirstName = CASE WHEN ImportBatch = 7 THEN LastName  ELSE FirstName END,
    LastName  = CASE WHEN ImportBatch = 7 THEN FirstName ELSE LastName  END;

After running the query above, I got the expected output shown in the screenshot below.

Both CASE expressions use the original row values, so the swap still works. The ELSE branches keep other rows unchanged. A WHERE clause is usually better, though, because it avoids touching rows you do not need to change. Every touched row writes to the transaction log, the file that records changes so SQL Server can recover and roll back.

Update in Batches

For millions of rows, one giant update can fill the log, hold locks for a long time, and block users. Update in batches instead. You can control the loop with a WHILE statement; see WHILE loops in a stored procedure.

DECLARE @BatchSize INT = 5000;
DECLARE @Rows INT = 1;

WHILE @Rows > 0
BEGIN
    UPDATE TOP (@BatchSize) dbo.Contacts
    SET FirstName = LastName,
        LastName  = FirstName,
        ImportBatch = -7          -- marks the row as fixed
    WHERE ImportBatch = 7;

    SET @Rows = @@ROWCOUNT;
END;

After running the query above, I got the expected output shown in the screenshot below.

This is an important design point. A swap is not idempotent, meaning running it twice returns the data to the original wrong state. Here, the batch marker changes from 7 to -7 as each row is fixed, so the loop never picks the same row twice. Without a marker, a retry could swap rows back. After the loop, update the marker to its final value if needed.

Pro Tip: In my experience, a swap without a “fixed” flag is a bug waiting for a retry. I either use a marker column like this or wrap everything in one transaction that I can cleanly roll back.

Swap Values Between Two Tables or Rows

Sometimes the values you need to swap live in different places. If the correct values are in another table, use an update with a join. See updating a table from another table. For loading corrected data into a staging copy first, see INSERT INTO … SELECT and creating a temp table from a SELECT.

If the goal is to swap the column names instead of the values, that is a metadata change. You can rename columns, but it breaks code, views, and reports that use the old names. Review how to rename a column in SQL Server before trying that on a shared system. For large tables, a name swap is fast because it changes no data, but it is riskier for applications. Check dependencies first.

Pro Tip: I avoid renaming columns in a shared database unless I have a list of every query and report that uses them. Swapping data is reversible with a backup. A silent app break is much harder to trace.

Frequently Asked Questions

How do I swap two column values in SQL Server?

Use one UPDATE with both assignments, such as SET A = B, B = A. SQL Server reads the original row values for both, so no temporary column is needed. Preview with SELECT and use a WHERE clause.

Can I swap columns without a temporary variable?

Yes, in SQL Server a single UPDATE handles it. Some other database systems evaluate assignments differently, so test on sample data if you use another platform.

How do I swap two columns with different data types?

Convert explicitly with CAST or TRY_CONVERT and test for failures first. Also compare column lengths and nullability, because truncation and NULL violations are common errors.

Can I undo a column swap?

Yes, if you saved the original data, used a transaction that you can roll back, or have a backup. Azure SQL Database also supports point-in-time restore within your retention period.

Is swapping column names the same as swapping values?

No. Renaming changes metadata only and can break queries, views, and apps that use the old names. Swapping values changes the data in each row.

You learned how to swap two column values in SQL Server with a single UPDATE, why it avoids data loss, and how to preview, log, batch, and recover from the change. Before any swap on real data, save the original values and confirm you can restore them. I hope you found this article helpful.

You May Also Like

• How to alter a table in SQL Server
• How to combine two columns in SQL
• How to change a column to NOT NULL in SQL Server
• How to check if a column exists in SQL Server
• How to find a table with a column name in SQL Server

That is why the SQL query to count employees in each department deserves more care than its size suggests. The basic version is three lines. A reliable version has to handle empty departments, unassigned employees, inactive staff, NULLs, and growing tables. This guide builds the query step by step in T-SQL, then covers performance, reusable objects, and secure access in Azure SQL Database or SQL Server, so you can ship a headcount report you can trust.

Set Up the Employee and Department Tables

A schema is the structure of your tables and how they relate. Start with two tables: one row per department, and one row per employee.

CREATE TABLE dbo.Departments (
    DepartmentID   INT IDENTITY(1,1) PRIMARY KEY,
    DepartmentName VARCHAR(100) NOT NULL UNIQUE
);

CREATE TABLE dbo.Employees (
    EmployeeID   INT IDENTITY(1,1) PRIMARY KEY,
    FullName     VARCHAR(150) NOT NULL,
    DepartmentID INT NULL
        REFERENCES dbo.Departments(DepartmentID),
    HireDate     DATE NOT NULL,
    IsActive     BIT NOT NULL DEFAULT 1
);

After running the query above, I got the expected output shown in the screenshot below.

DepartmentID in Employees is a foreign key, a rule that stops an employee from pointing to a department that does not exist. It allows NULL here on purpose, because new hires are sometimes unassigned. Review the basics in creating a table with a primary key and foreign keys in SQL Server.

Now load sample data. Run this only on a test database, because it inserts rows.

INSERT INTO dbo.Departments (DepartmentName)
VALUES ('Engineering'), ('Sales'), ('HR'), ('Legal');

INSERT INTO dbo.Employees (FullName, DepartmentID, HireDate, IsActive)
VALUES
 ('Ava Chen',   1, '2022-03-01', 1),
 ('Ben Ortiz',  1, '2023-06-15', 1),
 ('Cara Singh', 1, '2021-01-10', 0),
 ('Dan Weber',  2, '2024-02-20', 1),
 ('Eli Brooks', 2, '2020-09-05', 1),
 ('Fay Nolan',  3, '2023-11-30', 1),
 ('Gus Reyes', NULL, '2026-10-01', 1);

After running the query above, I got the expected output shown in the screenshot below.

This gives you Engineering with three people (one inactive), Sales with two, HR with one, Legal with none, and one employee with no department. Those edge cases are deliberate. Each one breaks a careless query.

Pro Tip: In my experience, a tiny seed dataset with an empty department, a NULL department, and an inactive employee finds more headcount bugs than a million random rows. I build one before writing any report query.

Basic SQL Query to Count Employees in Each Department

The core idea is GROUP BY plus COUNT. GROUP BY splits rows into buckets, and COUNT is an aggregate function that returns one number per bucket. For the fundamentals, see how to use GROUP BY in SQL Server and the COUNT function.

SELECT
    DepartmentID,
    COUNT(*) AS EmployeeCount
FROM dbo.Employees
GROUP BY DepartmentID;

After running the query above, I got the expected output shown in the screenshot below.

This groups employees by DepartmentID and counts the rows in each group. It works, but the output is just numbers. Also, the group with a NULL DepartmentID appears as its own row, which is correct but confusing without a label.

To show department names, join to Departments. A join combines rows from two tables based on a matching column. See this inner join tutorial.

SELECT
    d.DepartmentName,
    COUNT(e.EmployeeID) AS EmployeeCount
FROM dbo.Departments AS d
INNER JOIN dbo.Employees AS e
    ON e.DepartmentID = d.DepartmentID
GROUP BY d.DepartmentName
ORDER BY EmployeeCount DESC;

After running the query above, I got the expected output shown in the screenshot below.

The aliases d and e shorten the table names; read about SQL aliases if they are new. ORDER BY ... DESC puts the largest department first; see ORDER BY in SQL Server.

This query is the one that hid the Legal department. An INNER JOIN returns only departments that have matching employees, so empty ones vanish.

Pro Tip: I treat any headcount report built on an INNER JOIN as suspect until I have tested it with an empty department. That single test catches the most common version of this bug.

SQL Query to Count Employees in Each Department, Including Empty Ones

Use a LEFT JOIN, which keeps every row from the left table even when there is no match on the right. Read more in SQL LEFT JOIN.

SELECT
    d.DepartmentName,
    COUNT(e.EmployeeID) AS EmployeeCount
FROM dbo.Departments AS d
LEFT JOIN dbo.Employees AS e
    ON e.DepartmentID = d.DepartmentID
GROUP BY d.DepartmentName
ORDER BY d.DepartmentName;

After running the query above, I got the expected output shown in the screenshot below.

Legal now appears with a count of 0. The key detail is COUNT(e.EmployeeID). When you count a specific column, SQL Server skips NULLs, and a department with no employees produces a single row where every e. column is NULL. If you wrote COUNT(*) instead, that one placeholder row would count as 1, and Legal would show one employee.

You rarely need DISTINCT here because EmployeeID is already unique. It matters when your join can repeat employees, for example when joining to a table of project assignments. See COUNT DISTINCT for details, and how SQL treats NULL for why the counts behave this way.

Pro Tip: I make COUNT(column_from_the_right_table) a habit in every left-join count. It reads as the intent, which is to count matches, and it prevents the phantom row problem.

Filter Active Employees Without Breaking the Join

Most reports should count only active staff. The trap is where you put the filter. Putting it in WHERE quietly turns the LEFT JOIN back into an inner join.

-- Wrong: Legal disappears again
SELECT d.DepartmentName, COUNT(e.EmployeeID) AS EmployeeCount
FROM dbo.Departments AS d
LEFT JOIN dbo.Employees AS e ON e.DepartmentID = d.DepartmentID
WHERE e.IsActive = 1
GROUP BY d.DepartmentName;

After running the query above, I got the expected output shown in the screenshot below.

Why does this fail? WHERE runs after the join. For Legal, e.IsActive is NULL, and NULL = 1 is not true, so the row is removed. Move the condition into the ON clause so it applies before unmatched rows are added back.

SELECT
    d.DepartmentName,
    COUNT(e.EmployeeID) AS ActiveEmployees
FROM dbo.Departments AS d
LEFT JOIN dbo.Employees AS e
    ON e.DepartmentID = d.DepartmentID
   AND e.IsActive = 1
GROUP BY d.DepartmentName
ORDER BY ActiveEmployees DESC;

After running the query above, I got the expected output shown in the screenshot below.

With the sample data, the result is Engineering 2, Sales 2, HR 1, and Legal 0. Cara Singh is inactive, so she is excluded. For a refresher on filtering rules, read JOIN vs. WHERE.

Pro Tip: In my experience, “my left join lost rows” is almost always a right-table filter sitting in WHERE. When I review code, that is the first place I look.

Find Departments Above or Below a Size

To show only departments that meet a size rule, use HAVING. It filters groups after aggregation, while WHERE filters rows before it. The difference is explained in HAVING vs. WHERE.

SELECT
    d.DepartmentName,
    COUNT(e.EmployeeID) AS ActiveEmployees
FROM dbo.Departments AS d
LEFT JOIN dbo.Employees AS e
    ON e.DepartmentID = d.DepartmentID
   AND e.IsActive = 1
GROUP BY d.DepartmentName
HAVING COUNT(e.EmployeeID) >= 2;

After running the query above, I got the expected output shown in the screenshot below.

This returns only departments with at least two active employees. Change the condition to = 0 to list empty departments, which is useful for cleaning up stale data. To get just the biggest department, combine the count with the TOP clause.

Show Unassigned Employees and Percentages

Gus Reyes has no department, so he does not appear in any of the queries above. A report that silently drops people is a data quality problem. Handle it explicitly with COALESCE, which returns the first non-NULL value; see the COALESCE function.

SELECT
    COALESCE(d.DepartmentName, 'Unassigned') AS DepartmentName,
    COUNT(*) AS ActiveEmployees,
    CAST(100.0 * COUNT(*) / SUM(COUNT(*)) OVER () AS DECIMAL(5,1)) AS PercentOfTotal
FROM dbo.Employees AS e
LEFT JOIN dbo.Departments AS d
    ON d.DepartmentID = e.DepartmentID
WHERE e.IsActive = 1
GROUP BY COALESCE(d.DepartmentName, 'Unassigned');

Here the left table is Employees, so no employee can be lost. Using COUNT(*) is safe, because every row represents a real employee. The expression SUM(COUNT(*)) OVER () is a window function, which calculates across rows without collapsing them. It sums all group counts to give the total headcount, so each department’s share is easy to compute. Learn more in window functions in SQL Server and the OVER clause.

The trade-off: this version will not show empty departments, because it starts from Employees. If you need both empty departments and unassigned employees, use a FULL OUTER JOIN or UNION ALL the two result sets. I usually run the unassigned check as a separate data-quality query instead.

Pro Tip: I add an “Unassigned” row to headcount reports on purpose. Finance trusts a report more when its total matches the payroll count.

Make the Query Reusable and Fast

Once the logic is correct, save it. A view is a stored query you select from like a table. Read about SQL Server views.

CREATE OR ALTER VIEW dbo.vw_DepartmentHeadcount
AS
SELECT
    d.DepartmentID,
    d.DepartmentName,
    COUNT(e.EmployeeID) AS ActiveEmployees
FROM dbo.Departments AS d
LEFT JOIN dbo.Employees AS e
    ON e.DepartmentID = d.DepartmentID
   AND e.IsActive = 1
GROUP BY d.DepartmentID, d.DepartmentName;

Now every report reads from one definition, so “headcount” means the same thing everywhere. The view exposes only counts, not employee names, which also limits what a report user can see.

Add an Index

An index is a sorted structure that helps SQL Server find rows without reading the whole table. For counting by department, an index on the foreign key column helps. See how to create an index in SQL Server.

CREATE NONCLUSTERED INDEX IX_Employees_Department_Active
ON dbo.Employees (DepartmentID)
INCLUDE (IsActive);

The index lets SQL Server count rows from a narrow, sorted structure instead of scanning full employee rows. INCLUDE (IsActive) carries the filter column so the query does not need extra lookups. The trade-off is slightly slower inserts and updates, plus extra storage. On a table with a few hundred rows, you won’t notice a benefit. It starts to matter at hundreds of thousands of rows or more.

Check the actual execution plan before and after, and keep statistics current. For more tuning ideas, see SQL query optimization tips.

Pro Tip: I enable Query Store in Azure SQL Database before tuning anything. It keeps runtime history, so I can show that an index helped instead of assuming it did.

Frequently Asked Questions

What is the SQL query to count employees in each department?

Join employees to departments, then use GROUP BY on the department name with COUNT. For example, SELECT d.DepartmentName, COUNT(e.EmployeeID) FROM Departments d LEFT JOIN Employees e ON e.DepartmentID = d.DepartmentID GROUP BY d.DepartmentName. The left join keeps empty departments.

Why does my query show 1 for a department with no employees?

You are using COUNT(*) after a LEFT JOIN. The unmatched row still counts as a row. Use COUNT(e.EmployeeID) so NULLs are skipped.

How do I count only active employees?

Put the active condition in the ON clause of the left join, such as AND e.IsActive = 1. If you put it in WHERE, departments with no active employees disappear.

How do I list departments with more than five employees?

Add a HAVING COUNT(e.EmployeeID) > 5 clause after GROUP BY. HAVING filters after the counts are calculated, which WHERE cannot do.

How can I make this query faster?

Index the DepartmentID column in Employees, keep statistics current, and read the actual execution plan to confirm the index is used. For repeated reports, store the logic in a view so every consumer uses the same tuned query.

You now know how to write a SQL query to count employees in each department using GROUP BY, LEFT JOIN, COUNT on the right column, and HAVING, and how to avoid the empty-department and NULL traps. Test every headcount query with an empty department and an unassigned employee, and give report users read access to a view, not the employee table. I hope you found this article helpful.

You May Also Like

• SQL SELECT query examples
• How to use the SUM function in SQL Server
• How to use the AVG function in SQL Server
• How to use the MAX function in SQL Server
• SQL cheat sheet

That is the real challenge behind how to calculate total sales in SQL. The SUM function is easy. Choosing the right rows, avoiding duplicate counting, handling NULLs, and keeping the query fast on millions of orders is the hard part. This guide walks through a complete example with T-SQL, then covers security, performance, and Azure SQL considerations, so you can build a total sales query you can trust.

Set Up a Realistic Sales Schema

A schema here means the design of your tables and how they relate. Good totals start with good structure. Use a simple e-commerce model with orders and order lines.

CREATE TABLE dbo.Orders (
    OrderID     INT IDENTITY(1,1) PRIMARY KEY,
    CustomerID  INT NOT NULL,
    OrderDate   DATETIME2(0) NOT NULL,
    Status      VARCHAR(20) NOT NULL   -- Completed, Cancelled, Returned
);

CREATE TABLE dbo.OrderItems (
    OrderItemID INT IDENTITY(1,1) PRIMARY KEY,
    OrderID     INT NOT NULL
        REFERENCES dbo.Orders(OrderID),
    ProductID   INT NOT NULL,
    Quantity    INT NOT NULL,
    UnitPrice   DECIMAL(10,2) NOT NULL,
    Discount    DECIMAL(10,2) NULL      -- amount off the line
);

After running the query above, I got the expected output shown in the screenshot below.

This creates two tables. Orders holds one row per order, and OrderItems holds one row per product on that order. The REFERENCES clause creates a foreign key, a rule that stops an item from pointing to an order that does not exist. If you want to review these basics, see how to create a table with a primary key and how a foreign key works in SQL Server.

I use DECIMAL(10,2) for money, not FLOAT. Floating-point types store approximate values, so totals can drift by fractions of a cent. Decimal types store exact values, which matters when finance checks your numbers.

Pro Tip: In my experience, the “sales total” bugs I see most often come from the data model, not the SQL. Before writing any query, decide which table is the source of truth for revenue. For most systems it is the line items, not a total column on the order header.

Below is the insert query:

SET XACT_ABORT ON;
BEGIN TRY
    BEGIN TRANSACTION;

    DECLARE @OrderID INT;

    -- Order 1: completed, one NULL discount
    INSERT INTO dbo.Orders (CustomerID, OrderDate, Status)
    VALUES (101, '2026-10-03 10:15:00', 'Completed');
    SET @OrderID = SCOPE_IDENTITY();

    INSERT INTO dbo.OrderItems (OrderID, ProductID, Quantity, UnitPrice, Discount)
    VALUES (@OrderID, 1, 2, 25.00, 5.00),
           (@OrderID, 2, 1, 40.00, NULL);

    -- Order 2: completed, one NULL and one zero discount
    INSERT INTO dbo.Orders (CustomerID, OrderDate, Status)
    VALUES (102, '2026-10-12 14:40:00', 'Completed');
    SET @OrderID = SCOPE_IDENTITY();

    INSERT INTO dbo.OrderItems (OrderID, ProductID, Quantity, UnitPrice, Discount)
    VALUES (@OrderID, 3, 3, 10.00, NULL),
           (@OrderID, 1, 1, 25.00, 0.00);

    -- Order 3: cancelled, should be excluded from sales
    INSERT INTO dbo.Orders (CustomerID, OrderDate, Status)
    VALUES (101, '2026-10-20 09:05:00', 'Cancelled');
    SET @OrderID = SCOPE_IDENTITY();

    INSERT INTO dbo.OrderItems (OrderID, ProductID, Quantity, UnitPrice, Discount)
    VALUES (@OrderID, 2, 2, 40.00, NULL);

    -- Order 4: completed, discount on the line
    INSERT INTO dbo.Orders (CustomerID, OrderDate, Status)
    VALUES (103, '2026-10-28 16:30:00', 'Completed');
    SET @OrderID = SCOPE_IDENTITY();

    INSERT INTO dbo.OrderItems (OrderID, ProductID, Quantity, UnitPrice, Discount)
    VALUES (@OrderID, 4, 4, 12.50, 2.50);

    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION;
    THROW;
END CATCH;

After running the query above, I got the expected output shown in the screenshot below.

The Basic Way to Calculate Total Sales in SQL

The simplest approach is to multiply quantity by price for each line and add everything up with SUM. SUM is an aggregate function, which means it collapses many rows into one value. For more on the function itself, read how to use the SUM function in SQL Server.

SELECT SUM(Quantity * UnitPrice) AS TotalSales
FROM dbo.OrderItems;

After running the query above, I got the expected output shown in the screenshot below.

This multiplies quantity by unit price on every row, then adds the results. It is correct as a starting point, but it is rarely the number the business wants. It includes cancelled orders, ignores discounts, and covers all time.

Filter to the Right Orders

A total sales number should only include orders that count as revenue. Join to Orders and filter by status. An inner join returns only rows that match in both tables; see this inner join tutorial for more detail.

SELECT SUM(oi.Quantity * oi.UnitPrice) AS GrossSales
FROM dbo.Orders AS o
INNER JOIN dbo.OrderItems AS oi
    ON oi.OrderID = o.OrderID
WHERE o.Status = 'Completed';

After running the query above, I got the expected output shown in the screenshot below.

The WHERE clause removes cancelled and returned orders before the sum happens. If you are unsure when to filter in WHERE and when to use HAVING, see HAVING vs. WHERE. In short, WHERE filters rows before grouping, and HAVING filters groups after.

Pro Tip: I always run SELECT COUNT(*) and a quick sample of rows before trusting a new total. If the row count is surprising, the join or filter is wrong, and no amount of correct arithmetic will fix it.

Handle Discounts and NULL Values

A NULL is a missing or unknown value, not zero. In SQL Server, any arithmetic with NULL returns NULL. If Discount is NULL on some rows, Quantity * UnitPrice - Discount turns into NULL for those rows, and SUM silently ignores them. Your total drops with no error.

Use COALESCE, which returns the first non-NULL value in a list. See the COALESCE function and how SQL handles NULL for more detail.

SELECT
    SUM(oi.Quantity * oi.UnitPrice) AS GrossSales,
    SUM(COALESCE(oi.Discount, 0))   AS TotalDiscounts,
    SUM(oi.Quantity * oi.UnitPrice - COALESCE(oi.Discount, 0)) AS NetSales
FROM dbo.Orders AS o
INNER JOIN dbo.OrderItems AS oi
    ON oi.OrderID = o.OrderID
WHERE o.Status = 'Completed';

After running the query above, I got the expected output shown in the screenshot below.

This returns three values. Gross sales is revenue before discounts. Net sales subtracts discounts. Showing both avoids arguments later, because different teams often mean different things by “total sales.”

If your result looks rounded oddly, review formatting numbers to two decimal places. If you see a conversion error when your price column is stored as text, read the varchar to numeric conversion error. The better fix is to store numbers as numeric types in the first place.

Pro Tip: I have seen a nullable discount column quietly cut a quarterly report by thousands of dollars. Where possible, make money columns NOT NULL DEFAULT 0, so this mistake cannot happen.

Calculate Total Sales by Date Range

Most real questions are “how much did we sell this month?” Use a half-open date range, meaning start date included and end date excluded.

SELECT SUM(oi.Quantity * oi.UnitPrice - COALESCE(oi.Discount, 0)) AS NetSales
FROM dbo.Orders AS o
INNER JOIN dbo.OrderItems AS oi
    ON oi.OrderID = o.OrderID
WHERE o.Status = 'Completed'
  AND o.OrderDate >= '2026-10-01'
  AND o.OrderDate <  '2026-11-01';

After running the query above, I got the expected output shown in the screenshot below.

I avoid BETWEEN for datetime columns. BETWEEN '2026-10-01' AND '2026-10-31' stops at midnight on October 31 and drops almost the entire last day. The half-open pattern includes every moment of October and nothing from November. For more, see filtering by date and using BETWEEN with dates.

Also keep the date column unwrapped. Writing WHERE YEAR(o.OrderDate) = 2026 blocks index use, which forces SQL Server to scan more data. Comparing the raw column to a range lets the optimizer seek instead.

Pro Tip: In my experience, month-end reports break when someone uses BETWEEN with a time component. Make the half-open range your team’s standard and put it in your code review checklist.

How to Calculate Total Sales in SQL by Customer and Month

Business reports rarely need one number. They need totals per customer, product, or month. The GROUP BY clause splits rows into groups, and SUM runs once per group. See how to use GROUP BY in SQL Server for the fundamentals.

SELECT
    o.CustomerID,
    DATEFROMPARTS(YEAR(o.OrderDate), MONTH(o.OrderDate), 1) AS SalesMonth,
    SUM(oi.Quantity * oi.UnitPrice - COALESCE(oi.Discount, 0)) AS NetSales
FROM dbo.Orders AS o
INNER JOIN dbo.OrderItems AS oi
    ON oi.OrderID = o.OrderID
WHERE o.Status = 'Completed'
GROUP BY
    o.CustomerID,
    DATEFROMPARTS(YEAR(o.OrderDate), MONTH(o.OrderDate), 1)
ORDER BY SalesMonth, NetSales DESC;

After running the query above, I got the expected output shown in the screenshot below.

DATEFROMPARTS builds the first day of each month, which gives clean, sortable month labels. Every non-aggregated column in SELECT must appear in GROUP BY. For other grouping patterns, see grouping by date.

Avoid the Double-Counting Trap

This is the bug behind the $38,000 gap. Suppose Orders also had a OrderTotal column, and you wrote this:

-- Wrong: OrderTotal repeats once per line item
SELECT SUM(o.OrderTotal)
FROM dbo.Orders AS o
INNER JOIN dbo.OrderItems AS oi ON oi.OrderID = o.OrderID;

An order with five lines would add its header total five times. This is called fan-out, where a join multiplies rows from the “one” side. Sum values from the same grain, meaning the same level of detail. Either sum the order lines, or sum the header without joining to the lines.

If you ever need the number of orders, count distinct IDs rather than rows; see COUNT DISTINCT.

Pro Tip: I check every sales query by reconciling it against a simple independent total, such as a payment system export for one day. If the numbers differ, I look for fan-out first.

Add Running Totals and Rollups

Sometimes you need a cumulative total over time. Window functions perform calculations across related rows without collapsing them. The OVER clause defines the window; read more in window functions in SQL Server and the OVER clause.

WITH MonthlySales AS (
    SELECT
        DATEFROMPARTS(YEAR(o.OrderDate), MONTH(o.OrderDate), 1) AS SalesMonth,
        SUM(oi.Quantity * oi.UnitPrice - COALESCE(oi.Discount, 0)) AS NetSales
    FROM dbo.Orders AS o
    INNER JOIN dbo.OrderItems AS oi ON oi.OrderID = o.OrderID
    WHERE o.Status = 'Completed'
    GROUP BY DATEFROMPARTS(YEAR(o.OrderDate), MONTH(o.OrderDate), 1)
)
SELECT
    SalesMonth,
    NetSales,
    SUM(NetSales) OVER (ORDER BY SalesMonth
                        ROWS UNBOUNDED PRECEDING) AS RunningTotal
FROM MonthlySales
ORDER BY SalesMonth;

The CTE (common table expression) named MonthlySales is a temporary named result you can query right after it. The outer query then adds a running total across months. Specifying ROWS UNBOUNDED PRECEDING makes the frame explicit, and it is usually faster than the default frame.

For a grand total row on the same report, add GROUP BY ROLLUP:

SELECT
    o.CustomerID,
    SUM(oi.Quantity * oi.UnitPrice - COALESCE(oi.Discount, 0)) AS NetSales
FROM dbo.Orders AS o
INNER JOIN dbo.OrderItems AS oi ON oi.OrderID = o.OrderID
WHERE o.Status = 'Completed'
GROUP BY ROLLUP (o.CustomerID);

ROLLUP adds a final row where CustomerID is NULL and the value is the overall total. That NULL is the subtotal marker, so label it in your application.

Pro Tip: I use a CTE like this to keep the “calculate” step separate from the “present” step. It makes the query easier to test and easier for the next person to read.

Make the Calculation Reusable and Fast

Once the logic is right, package it. A view is a saved query you can select from like a table. Read about SQL Server views. A stored procedure is a saved, parameterized block of T-SQL; see how to create a stored procedure.

CREATE OR ALTER PROCEDURE dbo.usp_GetNetSales
    @StartDate DATE,
    @EndDate   DATE   -- exclusive
AS
BEGIN
    SET NOCOUNT ON;

    SELECT SUM(oi.Quantity * oi.UnitPrice - COALESCE(oi.Discount, 0)) AS NetSales
    FROM dbo.Orders AS o
    INNER JOIN dbo.OrderItems AS oi ON oi.OrderID = o.OrderID
    WHERE o.Status = 'Completed'
      AND o.OrderDate >= @StartDate
      AND o.OrderDate <  @EndDate;
END;

The procedure takes parameters, so the logic lives in one place. That prevents ten reports from computing “sales” ten different ways. SET NOCOUNT ON stops SQL Server from sending row-count messages, which reduces chatter.

Index for the Query

An index is a sorted structure that helps SQL Server find rows without scanning the whole table. For this workload, a nonclustered index on order date and status helps, and an index on OrderItems(OrderID) supports the join. Learn the basics in how to create an index in SQL Server.

CREATE NONCLUSTERED INDEX IX_Orders_Date_Status
ON dbo.Orders (OrderDate, Status)
INCLUDE (CustomerID);

CREATE NONCLUSTERED INDEX IX_OrderItems_OrderID
ON dbo.OrderItems (OrderID)
INCLUDE (Quantity, UnitPrice, Discount);

INCLUDE adds columns to the index leaf level so the query can be answered from the index alone. The trade-off is that every index slows inserts and updates and uses storage. Create them after checking the actual execution plan, not before. More tips are in SQL query optimization tips.

For heavy analytics on very large tables, a columnstore index stores data by column and compresses well, which can speed up large aggregations. Test it against your workload, since it suits reporting better than frequent single-row updates.

Pro Tip: I turn on Query Store in Azure SQL Database or SQL Server before tuning anything. It records query runtime history, so I can prove an index helped instead of guessing.

Frequently Asked Questions

How do I calculate total sales in SQL Server?

Multiply quantity by unit price for each order line and wrap it in SUM, such as SUM(Quantity * UnitPrice). Then filter to completed orders and the right date range. Subtract discounts for net sales.

How do I calculate total sales by month in SQL?

Use GROUP BY on the year and month of the order date, for example with DATEFROMPARTS. Then apply SUM to the line amounts. Add a window function if you want a running total.

Why is my SQL total sales number too high?

The usual cause is join fan-out, where an order-level value is repeated for each line item. Cancelled orders and duplicate rows can also inflate totals. Reconcile against a known number for one day to find it.

How do I include discounts in total sales?

Subtract the discount from each line amount before summing, and wrap nullable discount columns with COALESCE(Discount, 0). Report gross and net sales separately so teams agree on the definition.

How can I make sales queries faster?

Compare your date column directly to a range, index the join and filter columns based on the execution plan, and keep statistics updated. For very large reporting tables, consider a columnstore index and test it first.

You now know how to calculate total sales in SQL using SUM, JOIN, GROUP BY, COALESCE, and window functions, and how to avoid common mistakes like fan-out and NULL discounts. Always reconcile your result against an independent number, and give reporting users access to a specific view or procedure instead of the whole database. I hope you found this article helpful.

You May Also Like

• How to Find Percentage of Total in SQL
• How to Swap Two Column Values in SQL
• How to use the AVG function in SQL Server
• How to use the COUNT function in SQL Server
• How to use the MAX function in SQL Server
• How to use the MIN function in SQL Server
• SQL cheat sheet
• How to Find Even and Odd Numbers in SQL Server