wolfkillj (7/9/2013)

---

Carlo Romagnano (7/9/2013)

---

L' Eomot Inversé (7/9/2013)

---

Nice straightforward question. Good to see a question about another new feature in SQL 2012.

However, introducing a weird ODBC function into T-SQL seems to me a bad idea. It's treatment of NULL is a mechanism to allow people to continue to misuse null once the ability to switch ANSI nulls off is removed, and continue to write obscure buggy code instead of cleaning things up.

I guess the ability to write (for example) "concat(5,6,7,8)" and get 5678 might be considered useful, because it saves a bit of typing - not in the case of literals since "'5'+'6'+'7'+'8'" is 15 characters and so is the expression with concat - but when the arguments are column names "concat(c1,c2,c3,c4)" is quite a lot shorter than "cast(c1 as varchar)+cast(c2 as varchar)+cast(c3 as varchar)+cast(c4 as varchar)" but I don't believe the benefits of being able to do that (of similar things with float) outweigh the scope for misuse of this form of null handling, so on balance I feel concat is something I would rather live without.

CONCAT makes life easy!

While I can certainly see the advantages of replacing NULL arguments with empty strings, as does the CONCAT function, I also see Tom's point. Improper handling of NULLs already causes enough trouble, and it just seems like a function that doesn't require a developer to think consistently about the issue may encourage bad habits. Those bad habits could be especially troublesome when MS finally deprecates the ANSI_NULLS OFF and CONCAT_NULL_YIELDS_NULL OFF settings. MS is reintroducing behavior in the CONCAT function that it is eliminating in all other contexts by deprecating the CONCAT_NULL_YIELDS_NULL OFF setting.