In primo luogo, questo non è un "problema evidente di design". SQL è un linguaggio descrittivo dell'output, non un linguaggio procedurale che specifica come viene eseguita l'elaborazione. Non vi è alcuna garanzia dell'ordine di elaborazione, in generale, e questo è un vantaggio. Potrei dire che c'è un problema di progettazione, ma riguarda la gestione generale delle eccezioni nelle istruzioni SQL.
Secondo la documentazione di SQL Server (http://msdn.microsoft.com/en-us/library/ms181765.aspx), puoi dipendere dall'ordine di valutazione per un'istruzione CASE per espressioni scalari . Quindi, quanto segue dovrebbe funzionare:
select (case when isnumeric(c.varcharColumn) = 1 then cast(c.varcharColumn as int) end)
Oppure, per avvicinarsi a un'espressione "int":
select (case when isnumeric(c.varcharColumn) = 1 and c.varcharColumn not like '%.%' and c.varcharColumn not like '%e%'
then cast(c.varcharColumn as int)
end)
Almeno il tuo codice sta eseguendo un CAST esplicito. Questa situazione è molto più sgradevole quando i cast sono impliciti (e ci sono centinaia di colonne).
