Implicit conversion causing error part of the time
GeorgePalacios (imported from SE) 
I have been scratching my head about this one for the last day or so - I just can't see why a procedure works in one environment, but then fails in another due to a conversion error (same data, same code).

The plan for (a heavily cut down version of) the working server is here: https://www.brentozar.com/pastetheplan/?id=B1jZWTfOf

(This doesn't seem to be working, so I've uploaded the plan XML to pastebin here: [https://pastebin.com/47Q6nniw][1])

A bit of background for the relevant columns causing the problem:

The propertyInst table holds a column called ValueStr, which is an nvarchar data type. The GeneralLedgerCode table has a column id of data type int. Our developers are attempting to join between the two tables. The ValueStr column holds text data, XML data, int data, decimal data etc. As a matter of course we decided to add a function to ensure only integers are parsed (ISNUMERIC(ValueStr) = 1). What we didn't realise is that this would then also try to convert any decimal values - this is causing a conversion error in production of the nature:

Conversion failed when converting the nvarchar value '0.1' to data type int.

My question here is, given that the Table Scan of the propertyInst table will be picking up all numeric values including decimals, why is the implicit conversion in the scalar operator then not failing with the same conversion error? The output of the ISNUMERIC query returns some of these decimals. I can't see how the attached plan is working at all.

Does an implicit conversion operator never fail outright, and is the conversion error coming from the probe residual in the hash match operator? Then again, how could the value even make it to the operator when it would fail the implicit conversion?

As a small assistance, the plan image is here, with the Compute Scalar I'm asking about circled.

[![Plan][2]][2]

In addition, I can see that there are no actual rows logged against the scalar operator - does this mean the engine decided not to use that particular operator at runtime due to the conversion error?

[![Plan2][3]][3]

Any help would be appreciated.


  [1]: https://pastebin.com/47Q6nniw
  [2]: https://i.stack.imgur.com/S93iV.png
  [3]: https://i.stack.imgur.com/bNzJW.png
Top Answer
Mikael Eriksson (imported from SE) 
The calculation of the compute scalar operator is deferred to when it is actually used (the probe residual of Node ID = 1) and the rows that would have failed for you are filtered out by the previous Hash Match (Node ID = 3).

Have a look at [Compute Scalars, Expressions and Execution Plan Performance](https://www.sql.kiwi/2012/09/compute-scalars-expressions-and-execution-plan-performance.html) by Paul White for more information.

There is no indication in execution plans that evaluation of an expression is deferred, or when (at which node) it was actually evaluated. You can normally code defensively around this using `CASE` (which comes with an evaluation order guarantee) and/or `TRY_CONVERT`.

Related Microsoft feedback: [SQL Server should not raise illogical errors][1]


  [1]: https://feedback.azure.com/forums/908035-sql-server/suggestions/32912431-sql-server-should-not-raise-illogical-errors
comments
transcript

This room is for discussion about this question.

Once logged in you can direct comments to any contributor here.

Enter question or answer id or url (and optionally further answer ids/urls from the same question) from

Separate each id/url with a space. No need to list your own answers; they will be imported automatically.