Ah... but it wasn't "Replaced" because it's still available and has not been deprecated.
Yes, just like *= can still be used. I always hated the phrase "legacy code" and thought it should be "family curse" code instead.
Unless you believe in the myth of seamless migratable code or have an absolute need to migrate code on a regular basis,
Well, I paid for my house on this myth. And wrote a series s of books on it. And been paid $$$ per day for it.
I fix code written by cowboy coders to get their dialect code into a portable format for major corporations.No real ship is one-SQL only today!
Five decades ago I used to do the same thing with FORTRAN. Remember that 80 – 90% of the cost of a system is in maintaining it, not in writing it. The more portable the code, the cheaer it is in the long run. Want to see all of the research by SEI, DOD, IBM I EEE, Weinberg, etc.?
I see nothing wrong with continuing to use GETDATE().
Gee, it does not port! Please a lowercase getdate(), so we will know that it came from the C programming language in UNIX so many decades ago. I find this makes the mindset errors easier to find.
they also screwed up by cutting out half the functionality of those data types. You can no longer do direct simple arithmetic to do simple things like subtracting a date/time from another to get elapsed time.<<
Do you know the ANSI/ISO standards for temporal math? Thanks to having done this with the original Sybase/UNIX model, they cannot implement the ANSI/ISO operations immediately. It will take time just as getting INNER, OUTER JOIN, MERGE, DATE and TIME took a few releases.
You and in I also continue to answer questions about how to recombine DATE and TIME because people think they need to split them apart when both are available because they don't understand either.<<
AMEN! Amen. I wish T–SQL had the extract () function from ANSI/ISO.
[It is better to use CAST(NULL AS DATETIME2(0)), so you have control and documentation].
Unless you're using SELECT/INTO, no it's not. You don't do that for hard coded dates and you don't need to do it for a NULL
The optimizer/compiler will remove the extra coding. But it is nice for people to see the data types. Also, some also select into in T-SQL dialect is not ANSI/ISO standard SQL. This is called a Singleton select and you might want to Google it. Nobody uses it. Those of us who speak real SQL, would use INSERT INTO instead. And our code would port
I also use "ELSE NULL END" or "CAST (NULL AS )" with CASE expressions, etc. for the same reason.