OUTER APPLY Fundamentals: Part 2
In Part 2 of this series we learn how OUTER APPLY can be used in your queries to return data, even when there are no matches between tables.
2026-08-12
2,980 reads
In Part 2 of this series we learn how OUTER APPLY can be used in your queries to return data, even when there are no matches between tables.
2026-08-12
2,980 reads
As database changesets accumulate over time, they gradually become more than deployment artifacts. This level explores how a well-organized changeset library evolves into a replayable representation of the database’s structural history, supporting not only reliable deployments but also reconstruction, auditing, and long-term maintainability. Through practical examples and a real-world case study, it shows why maintaining coherent Create and Rollback scripts continues to provide value long after a successful production deployment.
2026-08-05
637 reads
Learn the basics of the CROSS APPLY operator with a few examples in this short piece.
2026-07-27
4,966 reads
This article shows how the TRY_PARSE() and TRY_CONVERT() functions can be used to handle data quality issues and ensure that your software continues to function without throwing errors.
2026-07-13
3,673 reads
Learn about an alternative strategy for avoiding hardcoded literal values in SQL Server queries by using single-row views designed to mimic enum behavior.
2026-06-26
3,197 reads
As database development scales across multiple contributors, concurrency becomes an inherent aspect of the process. Changes that are individually correct may still conflict when developed against a shifting baseline. This level introduces a disciplined approach to managing parallel changesets by controlling their scope, identifying overlap, and resolving conflicts through realignment. By ensuring that only one changeset retains its original baseline while others are adapted accordingly, deployments remain predictable and consistent. Once released, changesets are treated as immutable, and further evolution proceeds through new, forward-only changes.
2026-06-24
1,138 reads
This level examines how a rehearsed changeset is transformed into production-ready deployment artifacts. By consolidating scripts into controlled execution units and validating the resulting artifacts, the approach ensures that production deployment remains predictable and aligned with what was proven during rehearsal.
2026-06-11 (first published: 2026-06-10)
1,108 reads
Introduction When developers first learn SQL aggregation, they usually start with the GROUP BY clause. It works well for summary reports because it combines multiple rows into a single result for each group. For example, you can calculate total sales per region or average salary per department. The limitation of GROUP BY appears when you […]
2026-06-05
4,322 reads
Learn a quick way to calculate distances without resorting to spatial calculations.
2026-05-08
2,392 reads
Level 2 formalizes the behavioral guarantees that a changeset must provide in order to be safely deployed and rolled back. It introduces the deployment contract, checkpoint semantics, and the structural scope of Create and Rollback scripts. Data changes are addressed through a dedicated Update mechanism, with clear boundaries and limitations. By the end of this level, a changeset becomes a predictable and well-defined unit that can be reasoned about independently of execution context.
2026-06-11 (first published: 2026-05-06)
1,217 reads
A RAG pipeline that answers questions in the demo is not the same thing...
By Steve Jones
“A multitude of bad ideas is necessary for one good idea” – from Excellent...
Yesterday I gave a talk for MSSQLTips called “Building a DBA Agent for Your...
I've got a web application for my side business. I've added a SQL Server...
Comments posted to this topic are about the item Looking for New Blood
Comments posted to this topic are about the item Server-Level Row Counts for Tables...
What types of secondary replicas are available for the Azure SQL Database Hyperscale edition?
See possible answers