Just my humble opinion but, except for the fact that the newer datatypes can use fewer bytes, they pretty much suck for me because you cannot do direct data math with them, which is non-ANSI/ISO compliant. The standards do say that EndDate-StartDate = Period and StartDate+Period = EndDate, etc.
Microsoft apparently realized the boo-boo they made because of all the people wanking about not being able to easily calculate periods to the millisecond but instead of fixing the real problem, they introduced DATEDIFF_BIG.
As for the EOMONTH function, I'd have much rather had an FOMONTH function that would return a DATETIME datatype.
So far as dates prior to 01 Jan 1753, I wouldn't use SQL Server for them if I needed to work with them because of all the calendar changes made prior to that date. In other words, the dates are actually incorrect prior to that date depending on which country and religion you're working with.
is pronounced "ree-bar
" and is a "Modenism
" for R
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".
"If "pre-optimization" is the root of all evil, then what does the resulting no optimization lead to?"
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)