Why has CAST(FieldName to float) failed in view but not in SELECT?

Question

I've just solved a problem but I'm still not sure what the problem is!
I have a data (staging) table with all values stored as text. The data is converted to the correct data-type and also aggregated somewhat in a view. A select statement with the conversion works. A select statement with the conversion and aggregation (GROUP
BY) works. Creating a view of the conversion and aggregation works. However, on selecting from the view (e.g. SELECT TOP 1000 * FROM ViewName) it fails saying it cannot convert from varchar to float. There are no visible characters in the field apart from
numbers between 0 and 9, a decimal point and sometimes a leading minus sign (-).
The fix? Cast to money and then cast to float.
The problem? I don't know! What was the problem? Some of the values had up to 10 decimal places. Was that a problem? Was it really an overflow error masquerading as conversion error? The longest strings present were:
-2.609763091
-0.082456066
-0.674010546
-2.563428427
-0.016109637
-0.313600766
-0.104452264
-0.853811384
-0.302529502
-0.000362354
-0.002961949
-0.319269185
-0.001970796
Would really like to know what caused this so I can spot it in future before it happens.
Cheers.
JCEH

Answer 1

One possibility is that the two execution plans are different.  The logical order of the way SQL processes the clauses a SELECT query is FROM, ON, OUTER, WHERE, GROUP BY, CUBE | ROLLUP, HAVING, SELECT, DISTINCT, ORDER BY, TOP.  (Actually that's
what I learned, now there are some additional things like APPLY, but for our purposes we can ignore them).  The important thing to know is that that is the LOGICAL order, but SQL is allowed (and often does) go change that order to anything it wants as
long as it returns the correct result. 
So, for example, if your FROM clause a number of rows and some of those rows contain data which would cause a CAST (or anything else) in the SELECT clause to fail, but those rows are eliminated by your WHERE clause.  Then SQL could do
FROM, WHERE, SELECT and the query works, or
FROM, SELECT, WHERE and the query fails.  And, in general, you cannot control which plan SQL will use.
So, for example, if you have a table named T with two integer columns I and J and some rows in the table have a value of 0 in the column J and you run
SELECT I/J FROM T WHERE J<>0
it might work and you might get a divide by zero error.  So one safe way to handle this is to write your query as
SELECT I/(CASE WHEN J <> 0 THEN J ELSE NULL END) WHERE J<>0
Another way would be to create a temp table and write an insert statement that inserted into that temp table only the rows where J<>0 and then do the query from the temp table.  Since that is two SQL commands, SQL is forced to do them in order,
it cannot combine them and reorder the processing, that would look like
Create Table #T(I int, J int);
Insert Table #T(I, J)
Select I, J FROM T WHERE J<>0;
Select I/J From #T;
Drop Table #T;
You could try doing the equivalent of one of those to your query and see if that makes the problem go away.
Now I know you are going to ask "Why did the view use to work and it doesn't anymore?" and "Why does using the view and the table return different results".  My guess is that you are getting different plans for the view and the table,
why that is, I don't know, it is often difficult to answer that type of question.  My best guess for why the view used to work, then you ALTERED it, and then changed it back to the original form and it fails even though it is exactly the same as the old
view that was working is, when you had the old view, then was a cached execution plan that was working.  That execution plan might have been created a good while ago.  When you ALTERED it, you, of course, got a new plan.  Then when you ALTERED
it back to the original form, it no longer had the plan it had been using, so had to create a new one, and this new plan was different than the old one.
Finally, if this is the cause of your problem, then you are not guaranteed that the convert to money, then to float is a permanent fix.  If you have column headers which cannot be converted to either money or float, then it could be the convert to money
then to float is enough to get SQL to do the WHERE first, then the SELECT.  But there is no guarantee that will be true forever.  Changes in your data distribution and release level of SQL might make that version do the select first and then the
where.
Tom