In SQL Server 2012, you probably would be better off avoiding string concatenation or complex math, as they created a function that seems to be just for you:
SELECT DATEFROMPARTS(2013, 8, 19);
Of course, improper storage of data in the first place can lead to problems - for example, what restriction prevents y = 2013, m = 2 and d = 31 from the table? You could wrap this with TRY_CONVERT() , but not so much:
SELECT TRY_CONVERT(DATE, DATEFROMPARTS(2013, 2, 31));
Error:
Msg 289, Level 16, State 1, Line 3
It is not possible to create a data type date; some of the arguments have invalid values.
So, to prevent bad data from falling into these three columns, you will need to use one of the aforementioned cumbersome approaches in a control constraint or trigger ...
... or...
... in any version, you can fix the table and save the date (or date and time) in the first place. You get all the benefits of automatic validation, as well as built-in date and time functions that you don't get with three separate unrelated integers. It is much better to pull out parts when you need them individually (with calculated columns, a view, or during a query) from a value that is guaranteed to be a date, than trying to rely on individual parts to form a valid date ...
source share