Tout d'abord, ce n'est pas un "problème de conception flagrant". SQL est un langage descriptif de la sortie, pas un langage procédural qui spécifie comment le traitement est effectué. Il n'y a aucune garantie de l'ordre de traitement, en général, et c'est un avantage. Je pourrais dire qu'il y a un problème de conception, mais il s'agit de la gestion générale des exceptions dans les instructions SQL.
Selon la documentation SQL Server (http://msdn.microsoft.com/en-us/library/ms181765.aspx), vous pouvez dépendre de l'ordre d'évaluation d'une instruction CASE pour les expressions scalaires . Donc, ce qui suit devrait fonctionner :
select (case when isnumeric(c.varcharColumn) = 1 then cast(c.varcharColumn as int) end)
Ou, pour se rapprocher d'une expression "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)
Au moins, votre code fait un CAST explicite. Cette situation est beaucoup plus désagréable lorsque les transtypages sont implicites (et qu'il y a des centaines de colonnes).
