|
Ex: ABC Company jr68@gmail.com 123 Main St Every record has a space before and after the email address. I just want jr68@gmail.com returned using a select. Thx
(comments are locked)
|
|
This is very similar in concept to an earlier question, in that you can get the answer the same way: a tally table. These things are pretty powerful and the performance is great. :-) Using the tally table, the answer from before--where you asked for getting a subsection of the data--is almost exactly the same as the one here: The only difference from my answer to that earlier post is adding in one more where clause, where we're looking for an @ sign followed eventually by a dot (which you're unlikely to find in non-email field). That's one of the many awesome things about the tally table: it helps you solve an entire class of pattern-search problems, just like the ones you're running into now.
(comments are locked)
|
|
+1 to Kevin, but another option for this would be to use a CLR Scalar function - write the code in C#, get it to return the result. They have a much lower performance overhead than T-SQL Scalar Functions, so can yield very positive results, especially in this sort of area (string manipulation) where SQL Server has traditionally been weak. Come off it Matt! OK, the routine I've given as an answer will process 100,000 rows in 7 seconds (Yup. I test 'em!). Surely that's fast enough for most purposes. Why then bother with all the overhead of C#?
May 13 '11 at 07:01 AM
Phil Factor
Well, to me, it's not really an overhead. I would be able to write, test & deploy a CLR function to do that quicker than the SQL Server one, which would then be re-usable when moving it to the BLL, which is where it should be... And I don't think that the CLR function would be quicker than an in-line SQL solution - but it would certainly be faster than a SQL Scalar Function... If I didn't think writing it in SQL was a viable method, I wouldn't have +1'd Kevin's answer :)
May 13 '11 at 07:13 AM
Matt Whitfield ♦♦
Agreed, a scalar TSQL function won't perform with industrial quantities of data. In-line SQL always looks awkward but it can really fly. I hope I'm not anti-CLR, but I wouldn't want to encourage people to use CLR instead of SQL purely because they think it will always outperform SQL. There are so many other issues that will influence that decision in commercial IT departments.
May 13 '11 at 08:38 AM
Phil Factor
Yep, definitely in agreement there. Just presenting another option really :)
May 13 '11 at 12:21 PM
Matt Whitfield ♦♦
(comments are locked)
|
(comments are locked)
|
|
Use Send DB Mail Procedure and Return Email id ...............
(comments are locked)
|


Thx! I will use this and learn how to use the Tally Table. It appears I will have a lot of these issues in the future so I must learn this concept. I will give it a shot.
This worked like a charm. The other responses are good as well but we do not have access to C#. We are strictly a MS SQL 2005 shop; so, all of my solutions must be in SQL which this is. I will now start using the Tally table for a lot of this string manipulation. Thanks Kevin and Jeff Moden.