Ian

Common Causes of “Multi-Part Identifier Could Not Be Bound” in SQL Server

by

If you’ve worked with SQL Server for a while, you’ve probably run into the dreaded 4101 error that looks something like Msg 4104, Level 16, State 1, Line X: The multi-part identifier “X.Y” could not be bound.

It’s one of those vague errors that doesn’t immediately tell you what’s wrong. Basically SQL Server is complaining because it doesn’t know how to resolve the reference you wrote. This is usually a column or alias.

Let’s take a look at the most common causes, with examples to make them easier to spot.

Read more

Split and Re-Aggregate Delimited Strings in SQL Server

by

Working with delimited strings in SQL Server can be messy. Maybe you inherited a table where a column holds multiple values separated by commas, or you need to take a list and break it apart before putting it back together in some aggregated form. While best practice is to normalize data into proper relational tables, sometimes you don’t control the schema. Or perhaps you’re just solving a one-off reporting need.

This article walks through how to split delimited strings into rows, process them, and then re-aggregate them back into a single string, all within SQL Server.

Read more

Handling Unix Timestamps in SQL Server

by

Unix timestamps (also known as epoch time) are a simple way of representing a point in time: the number of seconds that have passed since 00:00:00 UTC on January 1, 1970 UTC. They’re popular in APIs, logs, and systems that need a compact, language-neutral way to store time.

If you’re working with SQL Server, you’ll almost certainly run into Unix timestamps eventually. Either you’re getting them from an external system or you need to produce them for one. Let’s walk through how to handle them in SQL Server.

Read more

Understanding FORMATMESSAGE() in SQL Server

by

When you’re working with SQL Server, sometimes you don’t just want to throw an error. Sometimes you want to build a message you can actually use elsewhere. That’s where FORMATMESSAGE() comes in. Instead of immediately printing a message like RAISERROR does, FORMATMESSAGE() gives you the formatted string back so you can decide what to do with it. This could include logging it, storing it, displaying it, or simply passing it along.

In simple terms, you can think of it as a way to take a predefined message from sys.messages (or even a custom string you provide) and turn it into a neatly formatted output. This can be quite handy when you need more control over how messages are handled in your SQL workflows.

Read more

7 Ways to Extract Data from JSON in DuckDB

by

Most DuckDB distributions come with the JSON extension, and this extension is loaded upon first use. That means we can go ahead and run queries against JSON data right out of the box. One common task we’ll face when working with JSON is extracting data from within the JSON documents. This can include extracting scalar values, or extracting nested JSON from within the outer document.

DuckDB provides us with multiple ways to extract such data. The option we use will largely depend on our use case. Either way, here are seven options for extracting data from JSON documents in DuckDB.

Read more

OPENJSON() vs JSON_VALUE() When Parsing JSON in SQL Server

by

Working with JSON in SQL Server often comes down to choosing the right function for the job. Two of the most common options are OPENJSON() and JSON_VALUE(). Both are designed to pull data out of JSON documents, but they work in very different ways and are suited to different scenarios. Knowing when to use each one can save time and simplify your queries.

This article breaks down how OPENJSON() and JSON_VALUE() handle JSON parsing, what makes them different, and the situations where one might be a better fit than the other. Whether you are cleaning up nested JSON or just extracting a single value, understanding these functions will help you work more effectively with JSON data in SQL Server.

Read more

2 Ways to Format Numbers with Thousand Separators and Decimals in SQL Server

by

When you need to make numbers easier to read in SQL Server, adding thousand separators and controlling decimal places can make all the difference. This is especially true in reports or user-facing queries. Instead of squinting at a long string of digits, formatted output lets values like 1234567.89 appear as 1,234,567.89, making them much quicker to understand.

SQL Server offers a few ways to do this, but two stand out for their simplicity and reliability. The first is with the FORMAT() function, which gives you full control over how numbers look (and even supports different cultures). The second is the CONVERT() approach, which works well for quick, no-frills formatting when using the money data type. Both are easy to use, and I provide examples of each in this article.

Read more

Top 5 Data Conversion Errors in SQL Server and How to Avoid Them

by

Data conversion errors can be a frequent source of frustration when working with databases. And SQL Server is no exception. Such errors can interrupt workflows and lead to inconsistent results. While data conversion errors often happen during explicit conversions, they aren’t unique to this. Oftentimes the error can be due to an implicit conversion.

This article outlines five of the most common data conversion errors and provides practical steps to avoid them.

Read more

How to Replace INSTR() with CHARINDEX() and PATINDEX() in SQL Server

by

If you’ve worked with Oracle or MySQL before, you may have used the INSTR() function to find the position of a substring inside a string. But when you’re porting code to SQL Server, you’ll quickly notice that INSTR() isn’t available. Instead, you’ll need to use either CHARINDEX() or PATINDEX(), depending on what you’re trying to do.

The good news is that both functions are pretty straightforward once you know the difference. CHARINDEX() handles simple substring searches, while PATINDEX() adds the ability to use patterns. In this article, we’ll walk through how each one works and how you can swap them in when you’d otherwise use INSTR().

Read more