When working with temporary tables in SQL Server, one of the most common tasks is checking whether the table already exists before creating it. This prevents errors in the event the table already exists, and ensures your scripts run smoothly regardless of previous executions.
In this article, we’ll explore five different approaches to checking for temporary table existence in SQL Server.
Sometimes we get dates in a format that SQL Server has trouble with when we try to convert them to an actual DATE value. One example would be dates in MMDDYYYY format. While it might be easy to assume that SQL Server would be able to handle this easily, when we stop to think about it, this format is fraught with danger.
The MMDDYYYY format is ambiguous. While we might know that the first two digits are for the month, SQL Server doesn’t know this. Some countries/regions use the first two digits for the day (like DDMMYYYY). So if we get a date like, 01032025, how would SQL Server know whether it’s the first day of the third month, or the third day of the first month?
In SQL Server, we have several options when it comes to formatting a DATE or DATETIME value as MMDDYYYY. The two most common functions for formatting dates like this are CONVERT() and FORMAT().
When working with numbers in SQL Server, both ROUND() and FORMAT() can be used to round the numeric values to a given decimal precision. But that doesn’t mean we should use them interchangeably. Each function serves a different purpose and has its distinct use cases.
Checking which users are connected to a SQL Server can be useful for both performance and security. It helps database admins see who’s using the system, what applications they’re running, and from where. This makes it easier to troubleshoot issues like slow queries or high resource usage. It also helps spot unusual or unauthorized access, such as logins from unknown machines or at odd times. Regularly reviewing active connections is a simple way to keep the server running smoothly and securely.
Below are five queries we can use to check which users are connected to a SQL Server instance.
If you’re a Mac developer, setting up SQL Server locally is probably starting to feel like more trouble than it’s worth. Between workarounds like Docker, virtual machines, and third-party tools, just getting a working SQL Server environment on macOS is not exactly your run-of-the-mill installation.
Add to that Microsoft’s announcement to retire SQL Edge in September 2025 (SQL Edge was our only hope of installing SQL Server on a Mac without using a virtual machine), not to mention the impending retirement of Azure Data Studio in Feb 2026 (which we could use to connect to SQL Server), and you may start to wonder whether you should drop the whole idea of using SQL Server altogether.
The SQL rpad() function has been widely implemented across many major RDBMSs, including MySQL, Oracle, PostgreSQL, and MariaDB, to name just a few. But when it comes to SQL Server, we have a problem. SQL Server doesn’t currently provide us with an rpad() function.
But that’s not to say we can’t apply right padding in SQL Server. SQL Server still provides us with enough tools to get the job done. With a bit of work, we can get a similar result to what we might be able to achieve with rpad(). It may not be as elegant as a simple rpad() function, but at least it’s an option.
In SQL Server, Common Table Expressions (CTEs) are often used for readability and simplifying complex queries. While CTEs are most commonly used when running a SELECT query, we can also use CTEs to perform updates with the UPDATE statement. This can be useful when we need to reference the same set of data multiple times or want to update records conditionally.
Deleting rows in a SQL database can sometimes be a nerve-racking experience. What if you’re deleting the wrong rows? Or what if the business later tells you they want their data back?
Fortunately SQL Server provides us with an easy way to essentially “back up” any rows affected by a DELETE operation to a table.
This article looks at using the OUTPUT ... INTO clause to save a copy of deleted rows to another table.
If you’re getting an error that reads something like “Violation of PRIMARY KEY constraint ‘PK_CatId’. Cannot insert duplicate key in object ‘dbo.Cats’. The duplicate key value is (1)” in SQL Server, it’s because you’re trying to insert a duplicate value into a primary key column.
A primary key cannot contain duplicate values.
To fix this issue, you’ll need to change the value you’re trying to insert into the primary key column.