Press "Enter" to skip to content

Category: Error Handling

Upsert Patterns and Duplicate Keys in T-SQL

Ajay Dwivedi runs into an error:

I work with developers quite a lot. There are scenarios where data is received from various sources in an application, and asynchronously pushed to database in multiple sessions/connections.

There are situations where concurrency and transaction speed is high enough to cause below UPSERT code blocks to fail with error message like Cannot insert duplicate key row in object dbo.person with unique index ‘pk_person’

Click through for one way to do things. I will note that Ajay has concerns about the MERGE operator, but Hugo Kornelis took a deep dive into all of the known problems in MERGE and found that most of them were fixed. Hugo’s post does make it clear when using MERGE is a bad idea, as there are still some situations in which it won’t work effectively, but for something like this, it would be fine.

I’ll say that I’m generally not a fan of app locking. There are specific circumstances in which it’s the best answer, but those are rare. Here, I’d rather just use a ROWLOCK table hint or change the serialization level.

Leave a Comment

The Costs of Implicit Conversion

Andy Brownsword changes things around:

Implicit conversion happens in SQL Server when the engine detects a mismatch in data types and automatically converts from one type to another. This can be helpful as it makes different types interchangeable and is generally transparent to the client, but it can come with issues.

Usually the downside from implicit conversion is seen through performance impact. But we’ve got something a little different today – an inconsistent result set.

Read on for Andy’s example.

Leave a Comment

Building a Better Trigger

Steve Jones is done with mousetraps:

This seemed to work, but did it really?

The Problem

Let’s illustrate the big problem with this change. I’ll run this code:

Steve hit on one of the problems in trigger design, but there’s another problem that we often see. Steve’s code doesn’t have this problem, but quite often, people assume that rows update one at a time. But if you write a T-SQL UPDATE statement that affects five rows, the trigger fires once for all five. Steve correctly uses the inserted and deleted pseudo-tables to handle all changes, rather than just assuming a single row.

Leave a Comment

Troubleshooting Weird Issues

Chad Callihan says sometimes, the best answer is not to play the game:

After some database infrastructure changes related to phasing out the use of linked servers, I encountered issues with a setup tool used to build out new databases and other related features. One section of the tool was failing, and the errors indicated that there were still stored procedures utilizing linked servers, which was causing the problem. I asked myself a few questions on how best to proceed. Does the setup tool need to be updated? Do the related database procedures using linked servers need to be updated? Do the linked server changes made need to be rolled back altogether?

Read on for a proper Gordian Knot solution.

Comments closed

When All AG Nodes are Secondaries

Randy Knight demands quorum:

If you’ve encountered a situation where none of your SQL Server Always On Availability Group (AG) replicas become PRIMARY after a cluster failure — you’re not alone.  We recently had a customer with this exact scenario (AG won’t become primary after force quorum), and it is both uncommon and difficult to troubleshoot so I thought it would be worth posting about.

Click through for the scenario, what’s happening, and how to resolve this.

Comments closed

Split-Brain Scenarios in PostgreSQL Clusters

Semab Tariq knows that an application cannot serve two masters:

In this blog post, we will try to explore a critical failure condition known as a split-brain scenario that can occur in PostgreSQL HA clusters. We will first see what split-brain means, and then how it can impact PostgreSQL clusters, and finally discuss how to prevent it through architectural choices and tools available in the PostgreSQL ecosystem

Click through for an explanation of split-brain and what can cause this problem. Additionally, Semab includes several tips on how to limit the likelihood of a split-brain scenario occurring.

Comments closed

sqlcmd in SQL Server 2025 and Certificate Chain Not Trusted

Vlad Drumea points out a new thing to keep an eye on:

SQL Server 2025 provides ODBC sqlcmd version 17 which enforces an encrypted connection.

If you’re trying to use it to connect to instances that don’t have a CA-signed certificate or where TLS encryption was never properly configured, sqlcmd will throw the famous “certificate chain not trusted” error message:

Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : SSL Provider: The certificate chain was issued by an authority that is not trusted.
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Client unable to establish connection.

The proper answer to this is to get trusted certificates. The workaround is what Vlad describes, so click through for that.

Comments closed

“Can’t Determine Relationships between the Fields” in Power BI

Marco Russo and Alberto Ferrari explain an error:

When you create a Power BI matrix, you drag and drop columns in the matrix, then add some measures, and Power BI figures out on its own which combinations of values to show. The process is so intuitive that we mostly ignore the details. However, Power BI sometimes cannot figure out how to populate the matrix, thus producing the error: “can’t determine relationship between the fields”. Adding a measure fixes the problem, but why? In some other scenarios, Power BI shows many empty rows, eliminating many of them only when you add a measure. Power BI shows a subset of the values in other scenarios, even when no measure is involved.

Read on for the explanation.

Comments closed

The Unreliability of Microsoft Fabric

Brent Ozar points out some major issues:

The link https://aka.ms/fabricsupport takes you to a localized status page that almost always shows all green checkmarks – even when the service is on fire. During last month’s 12+hour overnight outage, people were screaming on Reddit overnight that things were down, but the status dashboard was showing all green. When Microsoft employees woke up, they asked if people were still having problems – and then eventually got around to updating the status page to reflect the outage when it was clear that things were really borked.

Redditors have resorted to relying on reporting Fabric outages to Statusgator, who then tracks the time gap between a burst of user outage reports, to the time Microsoft actually updates their status page – and it ain’t pretty:

Click through for Brent’s take and an embarrassingly bad post-mortem. Given that Microsoft Fabric is a software-as-a-service product, there’s an inherent level of trust necessary in using it: you’re relying upon the platform team to ensure things are running smoothly and that you get what you’re paying for. Incidents like this erode that trust. Outages themselves are bad but they do happen. The real problem is in not embracing the outage: be clear with customers on current status and cause, and ensure people can easily see the history of events.

Comments closed

SQL Agent “Success” on Failure

Todd Kleinhans does not believe that green is good:

Far too many times, I have seen DBA(s) and others have this false sense that if the Agent run status shows green, then everything must be ok.

Click through for a funny story about a gas station robbery and examples of how a SQL Agent job can report success but actually fail. You also see this a lot with replication or tasks that are asynchronous in nature: the task is reporting that we successfully started whatever operation, but that doesn’t mean the operation itself succeeded.

Comments closed