String manipulation in SQL Server can sometimes be tricky, especially when you don’t know exactly where the piece of text you need begins or ends. You might have data where the structure isn’t perfectly consistent, and you can’t rely on fixed positions. That’s where dynamic substring extraction comes in handy.
In this article we’ll look at how we can dynamically extract substrings from a string in SQL Server when we don’t know the start or end positions of those substrings, or their lengths.
Converting a string in DD/MM/YYYY format to a DATE type can be done in several ways in SQL Server. This article presents five options along with examples.
When you need to test queries, stored procedures, or reporting logic, having quick access to realistic data is imperative. While tools like INSERT...SELECT from other tables or importing CSV files are common, sometimes you just want to spin up a set of rows on the fly without messing with permanent tables. That’s where the VALUES clause can help.
The VALUES clause is usually seen in simple INSERT statements, but it can also be used directly in a SELECT statement to create inline datasets. This can be especially handy for mocking up scenarios, testing joins, or building quick prototypes.
Working with dates in SQL Server is usually quite straightforward. There’s a good range of date types and functions that we can use to manipulate date/time values.
But international date formats can undo all that simplicity in a heartbeat. Something as simple as casting a string into a DATETIME type can blow up depending on how the server interprets the input. This often happens when you’re dealing with applications or imports that don’t stick to a single culture or regional setting.
Let’s walk through an example and see why SQL Server behaves this way, and more importantly, how to handle it correctly.
When working with averages in SQL Server, it’s easy to assume that AVG() just takes all rows into account and calculates a simple mean. And that’s true. By default, AVG() includes every value in the column you point it to. But sometimes, you may want to average only unique values in that column, which is where DISTINCT comes into play.
Let’s explore this with a simple example.
When designing a SQL Server database, one of the first tasks is deciding what datatype to use for each column. A common rule of thumb is to choose a datatype that fits the largest value you expect to store. For example, if you know an INT will comfortably hold all expe1cted order quantities, then it seems like a safe choice.
But that logic can fall short in some cases. It completely ignores an important consideration – aggregate queries.
Dropping or modifying a column in SQL Server can look straightforward, but it often isn’t. That column might be referenced by other objects in the database, and removing it without checking can break things silently. Unlike dropping a whole table, where SQL Server is very strict about dependencies, column-level references are not always enforced or even tracked. That’s why it’s important to do some homework before making the change.
In programming, the word idempotent describes an operation that produces the same result no matter how many times it is executed. When applied to SQL, idempotence refers to queries or commands that don’t introduce unexpected changes if you run them repeatedly.
The whole idea is that after the first execution, additional executions should leave the database in the same final state. Not just error-free, but stable and predictable. This concept is especially important when writing scripts that may be re-executed, such as database migrations or automated deployments.
When you set up foreign key relationships in SQL Server, you have a choice for how changes in the parent table affect related rows in the child table. One option is SET NULL, which replaces the foreign key value with NULL whenever the parent row is deleted or updated.
This behavior is useful in scenarios where you’d rather keep the child record around but cut the link once the parent no longer exists. For example, if a project is deleted, you might want to keep related tasks but mark their ProjectId as NULL.
The problem is that it’s not always obvious which foreign keys are configured with SET NULL, especially in large databases. Fortunately, SQL Server’s system views make it possible to query this information directly.
When working with applications that serve people across different countries, you quickly realize that numbers aren’t always written the same way. A salary of 55,000.75 in the U.S. might be displayed as 55.000,75 in Germany or 55 000,75 in France. The decimal and thousands separators change depending on a user’s locale.
If you’re storing numbers in SQL Server but want to display them in a format that makes sense internationally, you’ll want to tap into SQL Server’s locale-aware formatting.