If you’re in a country that uses DD/MM/YYYY format for your dates, then you’ll likely find yourself needing to display the current date in that format when you generate reports or data that’s intended to be read by humans.
Here are four methods to format the current date as DD/MM/YYYY in SQL Server.
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.
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.
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.
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.
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.
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.
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().
Converting a string in ‘MM/DD/YYYY’ format to a DATE data type in SQL Server is a common task. Below are four options for getting the job done.
In relational database management systems (RDBMSs) like SQL Server, the primary key constraint is a fundamental element that uniquely identifies each record in a table and enforces data integrity. However, there are situations where you might need to drop and then recreate this constraint. Such situations could include modifying the primary key columns, changing data types, resolving design issues, etc.
Understanding how to safely remove and reapply primary key constraints is extremely important for maintaining database consistency and minimizing downtime during schema changes.
In this article, we’ll walk through how to safely drop and then re-add a primary key constraint without breaking your database.