TSQL working in 2008 but not in SQL Server 2014

Question

Hello,
We recently have been asked to move from SQL Server 2008 to SQL Server 2014. We are trying to run parallel tests and one of our queries that was working perfectly in 2008 is not working in 2014.
One of the filter on the our query(from 2008) is we convert a varchar field to date and compare it to anotehr calulated filed ("convert(date,Quick_Data_Start_Date) <= convert(date,(Year_ID_to_Use + '-' + Month_ID_to_Use + '-01'))").
This worked fine in 2008 but when i try to do similar operation in 2014 it returns no result.
For testing purposes, instead of converting the field to date format, i manully converted the actual value i.e. instead of using "convert(date,Quick_Data_Start_Date)" when i use "convert(date,'8/1/2014')" the code works fine.
The field "Quick_Data_Start_Date" comes from a pivot query.
When i create a temporary table for the pivot query and use the temporary table in  my code and then convert the field on fly the code works fine again.
Seems like the T sql is not able to convert the field from varchar to date on the fly when coming from a different query. We have tried changing the compatbility level to 100 as well and it still would not work.
Any suggestions and comments will be really helpful. Thanks.
Regards,
GM

Answer 1

Hello, here is my overall review:
The query is not optimized … agreed!  But that’s not the issue.
There are a number of indexes that could be created, a number of minor calculations or evaluation criteria that could be improved to make the query more efficient … again – AGREED.
The query “as is” runs in just under a minute (on SQL 2008 machine with less memory and slower hard drives).  Adding the indexes would take more time to add than they would save.
NONE of that should make the query NOT WORK.  These deficiencies might make it run more slowly, but should not cause the query to return no results.
“order by” shouldn’t make any difference because the query plan isn’t assuming or using any special order
The main table (~10 M rows) is using a clustered index scan (not efficient, but not the point)
The Time dimension table is using a non-clustered index seek (so the index is sorted but the data in the table is NOT physically sorted that way)
The pivot subquery is using clustered index scan (it’s only 6 rows, so who cares)
Once again, the order by might make it less efficient, but shouldn’t make it fail.  We get no errors or warnings – it just returns no rows.
Because the query DOES return results when we 
Either dump the Pivot query result into a #temp table(single row) and use the #temp table instead of the pivot query in the big SQL or  
The “input” tables are limited to X rows but DOES NOT when the inputs have more rows
        This strongly suggests a memory issue.
The server has 64 GB of RAM, but this probably isn’t enough to hold millions of rows and calculations.
Can we turn on some traces to see what’s happening to the data in the query?  How and what are we looking for?
Once the memory capacity is exceeded, SQL should be pushing these results to a temporary table (either in the local database or the tempdb).  Can we test to see if that is happening? 
How?
Is there a permissions issue?
I have successfully done large copies outside of SQL (copied 300+ GB file from one location to another) that had to use the disk instead of just memory … means the disk write operation
isn’t restricted from my user account.
I can also confirm that the account that runs the SQL Service (“Network Service” account) has full permissions to the drives and paths where the mdf and ldf files are stored (including
master and temp).
If this doesn’t work, our upgrade is basically frozen and cannot proceed.  I’m really out of ideas … anything?