Dear developers, stop rejecting me

I’m here to talk about rejection. Not the emotional kind. At least, not from actual humans.

No, my heartbreak comes from websites, apps, forms… Why don't they like me? What did I ever do to them? You’re probably wondering what on earth has made me feel so dramatic. Well, over the years, I've typed my name into countless websites and apps, and more often than I'd like to admit, it's been rejected.

As a developer myself, it didn't take long to find the culprit: that innocent little quote in my last name. So, consider this a lighthearted rant with a few helpful tips on how you can make sure people like me (and our troublesome punctuation marks) can use your software without a fight.

How many people are we talking about, really?

You might think this is just a tiny problem affecting a handful of people, but single quotes in names are a lot more common than most developers realize. In Ireland, for example, names like O'Brien, O'Connor, and O'Sullivan are everywhere. The "O'" prefix literally means "descendant of", and you'll find it in a huge number of traditional Irish surnames. Add in Irish families spread across the UK, the US, Canada, and Australia, and suddenly you're talking about millions of people whose names proudly carry that little quote.

And it's not just the Irish. In France, you'll find D'Arcy and D'Angelo. In parts of Africa and the Caribbean, you'll see similar patterns where an apostrophe is part of the linguistic structure of a name. Even some transliterated names from other languages include one to represent a sound or a glottal stop.

So, when your form says, "Last name is invalid", you're not just rejecting my name; you're turning away entire families, cultures, and histories. All because of one tiny character that your code didn't quite know how to love.

Why is this (still) a problem?

There are a few reasons why software doesn't really like quotes. First of all, in most programming languages, the single quote (') is a reserved character used to indicate where a string or character starts and ends. It's part of the grammar of the language itself.

So, when your name happens to contain one, like mine does, the code suddenly gets confused. It thinks the name is finished halfway through. Instead of "D'haeyer", the program sees "D" followed by… well, chaos.

For example:

const name = 'D'haeyer'; // 💥 Syntax error: unexpected identifier
const name = 'D\'haeyer'; // ✅ Works fine

To make that work, you need to escape the quote by prefixing it with a backslash or by using double quotes, depending on the language. It's one of those things every developer learns early on, often after a frustrating few minutes wondering why their code suddenly stopped compiling.

Most modern frontend frameworks actually do a great job of handling this for you. When you type your name into a form, they quietly escape all those tricky characters before sending them off to the server. In other words, by the time your data leaves the browser, it's usually in good shape.

Unfortunately, that's only half of the story. Once your name reaches the backend, things can still go horribly wrong, especially if the server passes it straight into a database query. And if that database happens to speak SQL, well… let’s just say it's about to have trust issues.

What is the actual issue?

There are basically 2 main problems I run into when entering my name into a form. Either the form throws an exception, or the validation just indicates that my last name is "Invalid".

I'm not quite sure which of the 2 is the worst. But I must say, telling me that my last name is invalid is mildly infuriating.

But enough about how I'm a delicate flower. Single quotes in SQL queries can actually be harmful. SQL Injection is still one of the most used ways to try and gain access to your database, tamper with the data, or even delete it.

Going back to the start of this paragraph: if an error occurs when I enter my last name, this usually means that the developer is totally unaware that something like SQL Injection exists and is just doing string concatenation to build SQL queries. Which, by the way, is a really bad idea!

// Dangerous: concatenating user input straight into SQL
string lastName = txtLastName.Text; // user input
string sql = "SELECT * FROM Users WHERE LastName = '" + lastName + "'";

using (var conn = new SqlConnection(connString))
using (var cmd = new SqlCommand(sql, conn))
{
    conn.Open();
    using (var rdr = cmd.ExecuteReader())
    {
        // ...
    }
}

When I enter my last name into this form, it will throw an exception because the concatenation produces invalid SQL. That's not really harmful by itself. But imagine entering foo'; DROP … the Users table; /* (sanitized here so the blog doesn’t think I’m attacking it) in the textbox. That could result in the Users table being dropped and your data deleted.

When my last name doesn't pass validation, it means the developer knows about SQL injection but doesn't know how to properly solve it. Blocking single quotes at validation time rejects perfectly legitimate names (O'Connor, D'Angelo, etc.) and still doesn’t fix the underlying problem if the backend continues to use string concatenation for SQL.

How do we fix it?

I've resorted more than once to just ignoring the character and simply writing "Dhaeyer" when a form is acting up. But why should I "correct" my last name when developers could handle it properly for me?

By now we've established that using string concatenation for SQL statements is a no-go. So, what's the proper way to fix it?

Well, that's quite easy. Most programming languages provide some concept of SQL parameters, which allow you to safely construct your statements using placeholders instead of injecting user input directly into the query. SQL parameters avoid injection because they treat user input strictly as data, never as part of the executable SQL. This means that even if a last name contains quotes, semicolons, or other special characters, the database interprets them literally rather than as SQL commands. SQL parameters actually do all the heavy lifting for you!

C# Example (ADO.NET)

string lastName = txtLastName.Text;
string sql = "SELECT * FROM Users WHERE LastName = @lastName";

using (var conn = new SqlConnection(connString))
using (var cmd = new SqlCommand(sql, conn))
{
    cmd.Parameters.AddWithValue("@lastName", lastName);
    conn.Open();

    using (var rdr = cmd.ExecuteReader())
    {
        while (rdr.Read())
        {
            Console.WriteLine(rdr["FirstName"]);
        }
    }
}

Why this is safe: The parameter @lastName ensures the user input is treated strictly as data, never as SQL code. Single quotes, semicolons, or anything else in the input won’t break the query.

Python Example (using sqlite3)

import sqlite3

conn = sqlite3.connect('example.db')
cur = conn.cursor()

last_name = input("Enter your last name: ")
cur.execute("SELECT * FROM Users WHERE LastName = ?", (last_name,))
rows = cur.fetchall()

for row in rows:
    print(row)

conn.close()

Why this is safe: The ? placeholder ensures the input is escaped and treated as data, preventing any injected SQL from executing.

What triggered me to write this?

"Haven't there been enough blog posts about SQL Injection?" you might think. I agree, measures to prevent SQL Injection and write safe code should be common knowledge by now. But I've noticed this issue popping up more over the last few months. Does this come with the trend of non-technical people vibe coding websites and forms nowadays? Or is it simply because developers use AI to write code without really thinking about what it generates? Difficult to say.

What I can say is that it's a frustration that we still see this problem in 2026. If forms keep rejecting me, I might just go full SQL injection and rename myself to Tim'); DROP … the Users table; -- (sanitized to avoid triggering security filters).

Bonus

I even had this error pop up in a place I would never expect. When working on some bicep changes for a customer I suddenly saw an error in my deployment pipeline.

Error BCP019: Expected a new line character at this location.

I started debugging and couldn't really figure out what the problem was. The error pointed me to this line in my bicep code:

param ReleaseInfo = 'Release #{Release.ReleaseName}#, triggered by #{Release.Deployment.RequestedFor}#'

The values between #{ }# gets replaced by actual values at deploy time. Turns out, bicep also doesn't really like my last name. Luckily, the fix was easy to do.

param ReleaseInfo = '''
Release #{Release.ReleaseName}#, triggered by #{Release.Deployment.RequestedFor}#
'''

Triple-quoted strings in Bicep (and many other languages, like Python) allow any character inside without needing escaping, including single quotes, double quotes, or newlines.

Was this "final drop" to make me finally write this blogpost? You bet!