CAST int to DATE failure when used with INNER JOIN - sql-server

Question

I have the following query:
SELECT
T2.PseudoDateColumn
FROM
(
SELECT
*
FROM T1
WHERE
PseudoDateColumn <> -1
) T2
INNER JOIN T3
ON T2.T2_key = T3.T3_key
WHERE
CAST(CAST(T2.PseudoDateColumn AS VARCHAR) AS DATE)
BETWEEN
DATEADD(mm, -1, DATEADD(mm, DATEDIFF(mm, 0, GETDATE()), 0))
AND DATEADD(ms, -3, DATEADD(mm, 0, DATEADD(mm, DATEDIFF(mm, 0, GETDATE()), 0)))
PseudoDateColumn is an int in T1. Values that aren't real dates have a -1 placeholder. All other dates are real dates (just stored as an int). Because of this, I need to first filter out all of the -1 values before I cast PseudoDateColumn to a DATE, such that I can use BETWEEN. When I run this script without the join, it works fine. But, when I run it with the join, SQL throws an error:
"conversion failed when converting date and/or time from character
string"
I don't know why this is happening. It's like SQL is doing the CASTing even before the sub-query.
Update:
I mistakenly wrote SQL Server 2008. I'm actually running this on PDW AU5, which has SQL Server 2012. I don't think that makes a difference, though.
Also, here is some sample data in PseudoDateColumn. All values are in the form YYYYMMDD.
PseudoDateColumn
-----------------
20150112
20160305
20111009

Answer 1

I know this is an old post but I think this can help someone. I had a similar error when trying to convert/cast a VARCHAR input parameter to a UNIQUEIDENTIFIER in my inner join. All my data was valid and the conversion worked just fine if done outside the join, but it would fail during the join. In fact I was even getting results in the results pane of SQL Server Management Studio but the error was still being thrown. What worked for me was to use TRY_CAST or TRY_CONVERT instead of CAST or CONVERT. My friendly neighborhood DBA suggested this solution because it ensures early execution or something like that.

Answer 2

The most likely explanation for the behavior is a "bad" value stored in the PseudoDateColumn. But you should be able to debug that.
Storing "date" values in an integer column seems like an anti-pattern to me, when SQL Server has a perfectly suitable DATE datatype custom designed for storing date values.
But if you need to work with what you already have, and address the issue without altering the schema definition...
SQL Server has an ISDATE function that you could use test test the validity of a character string. Unfortunately, the check that ISDATE performs isn't as strict as an actual CAST operation, but it does catch the most egregiously "bad" values.
My recommendation:
Instead of converting the integers to dates (the integer values stored in your column...
Cast/convert your literal DATE values to integer, into the same datatype/format as the column (integer), and do the comparison to the raw integer column.
So your query would be something like this:
WHERE T2.PseudoDateColumn >= CONVERT(INT, CONVERT(VARCHAR(8), datexpr1, 112) )
AND T2.PseudoDateColumn < CONVERT(INT, CONVERT(VARCHAR(8), datexpr2, 112) )
In that example, dateexpr1 and dateexpr2 would be replaced with expressions that return a DATE datatype, like the expressions in the original query.
NOTE: This type of range comparison depends on the stored integer values to be canonical. (With year first (four digits), then month (two digits), then day (two digits). In that representation, we are guaranteed that the comparison
(int)a <= (int)b < (int)c
will yield the same results as
(date)a <= (date)b < (date)c
(Equivalent apart from the differences due to "bad" integer values that can't be converted to a valid date... for example, an integer value with invalid "month" and/or "day" parts, e.g. 20161300 (month is thirteen, and day is zero)
An integer comparison that checks for pseudodates the 2016 would "work" for that without throwing an error...
20160101 <= 20161300 < 2017000 -> TRUE
This approach entirely avoids the issue of attempting to convert a "bad" psuedodate integer value into a DATE. But it's always possible to convert a valid DATE into an integer in YYYYMMDD format.
As an added benefit of this pattern, with predicates on the bare PseudoDateColumn column, SQL Server may be able to make effective use of an index that has PseudoDateColumn as the leading column.
If you are dead set on converting PseudoDateColumn to a DATE, you could first perform a conditional test that validates the value, using the ISDATE function. Something like this:
CASE WHEN ISDATE(CONVERT(VARCHAR(20), T2.PsedoDateColumn)) = 1
THEN CONVERT(DATE,CONVERT(VARCHAR(20), T2.PseudoDateColumn),112)
ELSE NULL
END