SQL Server has a COL_LENGTH() function and a DATALENGTH() function that could easily be confused for doing the same thing. They both have “length” in their name, and they do indeed return a “length”. But the length returned is different for each function.
If you’ve ever wondered why DATALENGTH() gives you different numbers than COL_LENGTH(), read on to find out.
When working with SQL Server, string concatenation is one of those everyday tasks that’s easy to take for granted. It can feel like second nature to reach for the trusty old + operator to piece together strings, but SQL Server also provides an alternative way to handle concatenations. Yes, I’m referring to the CONCAT() function.
And there’s a subtle difference between the two approaches that might sway you towards using one or the other.
Let’s compare these two approaches to building strings in SQL Server.
When you’re writing reports in SQL Server, one of the first little annoyances you’ll probably bump into is how percentages show up. By default, SQL Server doesn’t have a built-in “percent” data type. Percentages are usually stored as decimals (for example, 0.25 for 25%), and if you just throw those into a report, they won’t look the way people expect.
So you’ll need to do a bit of work to get it nicely formatted into a percentage format that people expect to see.
Also, if you’re calculating percentages from raw values then that will require some more work.
In this article we’ll walk through an example of how to calculate and format percentages in SQL Server.
Working with messy numeric data is one of those unavoidable realities in database development. Whether you’re importing data from CSV files, web APIs, or legacy systems, you’ll often encounter numeric values stored as strings with all sorts of unwanted characters mixed in. SQL Server’s conversion functions are pretty strict about what they’ll accept, so you need to clean up these strings before attempting any conversions.
When working with financial data in SQL Server, you may occasionally need to present numbers as formatted currency values. Storing currency amounts as DECIMAL or MONEY types is common, but these result in raw numbers like 1234.5, which don’t tell users which currency it’s in. With a bit of formatting logic, you can make query results easier to read and more meaningful.
When running queries in SQL Server, you’ll need to know which database your query is running against. If you’re using a GUI tool like SSMS, you’ll usually see the database expanded in the object explorer. Perhaps you even navigated to the database before opening a query window. In such cases, there will be no doubt which database you’re querying.
If you’ve been working with SQL Server for a while, you’ve probably come across the term “compatibility level” at some point. Maybe you’ve seen it in database properties or heard someone mention it during a migration discussion. But what exactly does it mean, and why should you care?
If you’ve written SQL long enough, you’ve probably run into the dreaded “Divide by zero error encountered” message. This happens when you try to perform a division and the denominator turns out to be zero. SQL Server throws an error immediately, which stops your query. This can be annoying, especially if the zero values are expected in the data but you don’t want them breaking your query.
One simple way to deal with this is by using the NULLIF() function.
When you work with dates in SQL Server, you’ll often run into situations where a value can’t be converted directly to a datetime or date. This usually happens because the source data isn’t in a format SQL Server recognises, or because the value itself is out‑of‑range (e.g., “2025‑02‑30”). Fortunately, the built‑in conversion functions CAST() and CONVERT() provide us with enough flexibility to clean up those problematic values without resorting to messy string manipulation.
Below we’ll look at the most common scenarios, show how to diagnose the issue, and demonstrate how to fix it.
At first glance, calculating an average in SQL Server seems straightforward. Just wrap a column in the AVG() function and you’re done. But there’s a subtle catch when working with integer columns. If you pass an integer to AVG() the result will be an integer, even if the actual average includes a fractional part. If you’re not aware of this when calculating averages, you could potentially draw the wrong conclusion from your query results.
Let’s unpack the behavior and then see how we can fix it.