May 21, 2018 at 10:22 am
Jeff,
I couldn't agree more. This is a code or process issue not a SQL issue. I have had this very argument with the person requesting this. But some people get an idea stuck in their heads and will not let go. If you do not mind. I would like to take your latest post and lay it in front of them. With a response of, see I am not the only one who think this is a fools errand. This needs to go to development.
May 22, 2018 at 9:09 am
TollHouse - Monday, May 21, 2018 10:22 AMJeff,
I couldn't agree more. This is a code or process issue not a SQL issue. I have had this very argument with the person requesting this. But some people get an idea stuck in their heads and will not let go. If you do not mind. I would like to take your latest post and lay it in front of them. With a response of, see I am not the only one who think this is a fools errand. This needs to go to development.
If you still get stonewalled, it might be because in the long run, it might actually be fairly easy to do in T-SQL. Checking a value against Luhn10 or to just validate that a character string has nothing but digits, dashes, and spaces, isn't really that challenging. Ensuring the length of a given segment could be more interesting, but probably not inherently difficult. And as one could certainly call it data validation, it's still viably in the realm of things SQL Server might be expected to do. It is fairly important for folks to recognize that mobile banking involves cell phone pics taking pictures of checks, as opposed to the normal process that MICR was actually invented to help secure. Such pictures are going to have a rather wide variety of quality, and eliminating the consumer behavior from that transaction is NEVER going to be perfect, nor is MICR recognition from such a photo ever going to be. There are way too many different cell phones, all of which are subject to fingerprints and skin oils getting on the outer lens of the cell phone camera, and variations in camera resolution, image brightness, image focus, and a consumer capable of actually taking a decent picture.. Expecting industry to solve that problem isn't all that realistic. Identifying errors is trivial, however, compared to correcting them.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
March 15, 2026 at 4:00 pm
Great question about pattern matching in SQL Server. Here's what I'd recommend:
For basic email validation, this pattern works well:
SELECT *
FROM users
WHERE email LIKE '%@%.%'
AND email NOT LIKE '%@%@%'
AND email NOT LIKE '% %';
However, if you need more robust validation, SQL Server 2025's new REGEXP functions are much more powerful:
SELECT *
FROM users
WHERE REGEXP_LIKE(email, '^[A-Za-z0-9._+]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$');
This checks:
At least one character before @
Valid domain format with dot
TLD with 2+ characters
Important notes:
For production, combine this with application-level validation
Consider DNS/MX checks if you need to verify deliverability
Test patterns thoroughly before deploying to production
For testing and generating these patterns interactively, I've been using regsql.com — it lets you validate SQL regex queries directly. Might save you some time.
March 15, 2026 at 4:00 pm
Great question about pattern matching in SQL Server. Here's what I'd recommend:
For basic email validation, this pattern works well:
SELECT *
FROM users
WHERE email LIKE '%@%.%'
AND email NOT LIKE '%@%@%'
AND email NOT LIKE '% %';
However, if you need more robust validation, SQL Server 2025's new REGEXP functions are much more powerful:
SELECT *
FROM users
WHERE REGEXP_LIKE(email, '^[A-Za-z0-9._+]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$');
This checks:
At least one character before @
Valid domain format with dot
TLD with 2+ characters
Important notes:
For production, combine this with application-level validation
Consider DNS/MX checks if you need to verify deliverability
Test patterns thoroughly before deploying to production
For testing and generating these patterns interactively, I've been using regsql.com — it lets you validate SQL regex queries directly. Might save you some time.
Viewing 4 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply