La Conversion de type datetime ne parvient pas uniquement sur la clause where?

Je vais avoir un problème avec certaines requêtes SQL server. S'avère que j'ai une table avec "Attibute_Name" et "Attibute_Value", qui peut être de tout type, stocké dans le type varchar. (Oui... je sais).

Toutes les dates d'un attribut en particulier semblent être stocké le "AAAA-MM-JJ hh:mm:ss" format (pas 100% sûr à ce sujet, il y a des millions d'enregistrements ici), donc je peut exécuter ce code sans problèmes:

select /*...*/ CONVERT(DATETIME, pa.Attribute_Value)
from 
    ProductAttributes pa
    inner join Attributes a on a.Attribute_ID = pa.Attribute_ID
where 
    a.Attribute_Name = 'SomeDate'

Cependant, si j'exécute le code suivant:

select /*...*/ CONVERT(DATETIME, pa.Attribute_Value)
from 
    ProductAttributes pa
    inner join Attributes a on a.Attribute_ID = pa.Attribute_ID
where 
    a.Attribute_Name = 'SomeDate'
    and CONVERT(DATETIME, pa.Attribute_Value) < GETDATE()

J'obtiens l'erreur suivante:
échec de la Conversion lors de la conversion de la date et/ou le temps de chaîne de caractères.

Comment se fait il échoue sur la clause where, et non sur la en choisir un?

Un autre indice:

Si, au lieu de filtrage par le Attribute_Name je utiliser le Attribute_ID stockées dans la base de données (PK), cela fonctionnera sans problème.

select /*...*/ CONVERT(DATETIME, pa.Attribute_Value)
from 
    ProductAttributes pa
    inner join Attributes a on a.Attribute_ID = pa.Attribute_ID
where 
    a.Attribute_ID = 15
    and CONVERT(DATETIME, pa.Attribute_Value) < GETDATE()

mise à Jour
Merci à tous pour les réponses. J'ai trouvé difficile de choisir une bonne réponse parce que tout le monde a montré quelque chose qui est utile à la compréhension de la question. C'est certainement d'avoir à faire à l'ordre de l'exécution.
S'avère que ma première requête a fonctionné correctement car la clause where a été exécuté en premier, puis le SÉLECTIONNER.
Ma deuxième requête a échoué à cause de la même raison (comme les Attributs n'ont pas été filtré, la conversion a échoué lors de l'exécution de la même clause where).
Mon troisième requête a fonctionné parce que l'ID a été le cadre d'un index (PK), donc il a fallu la priorité et il a foré les résultats sur la condition de la première.

Merci!

est-il un autre attribut appelé sOmeDaTe - dans le cas où vous utilisez un casse classement? Probablement son gâcher vos jointures.
Vous semblez être en supposant une sorte de court-circuit de l'évaluation ou de la garantie de commander des prédicats dans la WHERE clause. Ce n'est pas garanti. Lorsque vous avez mélangé les types de données dans une colonne comme que la seule façon de les traiter est avec un CASE expression.
Ce tableau est PHA? Si PHA est une table différente de PA il semblerait que la PHA de données unconvertable enregistrements, où que l'autorité palestinienne n'a pas.
Je sais pourquoi vous n'êtes pas sûr à 100% - si vous utilisez un VARCHAR colonne pour stocker des valeurs de date/heure, chacun est libre de stocker n'importe quelle vieille ordure là qu'ils veulent. Pour la VAE, j'ai toujours préféré les séparer dans ces colonnes appropriées pour au moins les trois types de base, un attribut de chaîne, un attribut de date/heure, et un attribut numérique. Il n'est pas parfait et ce n'est pas un libre-échange, mais vous avez une bien meilleure chance à assurer des données non valides reste en dehors de votre base de données.
Smith, je viens de lire Remus' article et j'ai enfin compris ce que vous avez dit. Vous avez raison, il est tout à fait compréhensible.

OriginalL'auteur Alpha | 2011-08-31