SQL “entre” ne sont pas inclus

J'ai une requête comme ceci:

SELECT * FROM Cases WHERE created_at BETWEEN '2013-05-01' AND '2013-05-01'

Mais cela ne donne pas de résultats, même si il existe des données sur la 1ère.

created_at ressemble 2013-05-01 22:25:19, je soupçonne qu'il a à faire avec le temps? Comment cela pourrait-il être résolu?

Il fonctionne très bien si je n'ai plus grandes plages de dates, mais il devrait (inclus) travaux avec une date unique aussi.

  • Eh bien, combien de numéros sont compris entre 1 et 1? Devrait 1.5 être comprise entre 1 et 1? il suffit de ne pas utiliser ENTRE de date et d'heure des plages. Jamais. Et faire attention à la façon dont vous évaluez "fonctionne très bien" - avez-vous inspecté de près les résultats de la dernière journée dans la gamme? Vous ne comprendraient que toutes les lignes si ils n'ont pas de temps associé avec eux.
InformationsquelleAutor JBurace | 2013-05-02
  1. 241

    Il est inclusive. Vous comparez datetimes de dates. La deuxième date est interprétée comme minuit quand la journée commence.

    Un moyen de résoudre ce problème est:

    SELECT *
FROM Cases
WHERE cast(created_at as date) BETWEEN '2013-05-01' AND '2013-05-01'

    Un autre moyen pour résoudre ce problème est explicite des comparaisons binaires

    SELECT *
FROM Cases
WHERE created_at >= '2013-05-01' AND created_at < '2013-05-02'

    Aaron Bertrand a une longue entrée de blog sur les dates (ici), où il discute de cela et d'autres problèmes de la date.

    • Par souci d'exhaustivité sur ce bonne réponse, je vous recommande d'utiliser dateadd pour obtenir le lendemain.
    • Pour le plaisir d'une réponse, je l'aurais utilisé l'ISO-8601 de "20130501'. Pour les personnes avec dateformat dmy, vous obtenez ceci: set dateformat dmy;select month(cast('2013-05-01' as datetime)); =1
    • Je crois que le explicite bit est à l'aide d'un intervalle fermé à une extrémité (>=) et ouvert à l'autre (<) combiné avec la fonction de vérification, un jour, au-delà de la date de fin spécifiée.
    • Ce genre de problème, c'est pourquoi j'ai choisi de représenter date/temps à l'interne tel que Modifié Julian nombre de Jour. Ils sont toujours à l'égard de l'UTC, dans la précision à la milliseconde avec juste un lit double, et peuvent être facilement converties en affichables formes. En outre, la date de l'arithmétique, de tri, de comparaisons, et la date à base de filtres sont facile à implémenter.
    • Personnellement, je pense qu'il serait ennuyeux d'avoir à les convertir à datetimes chaque fois que je voulais l'affichage, l'importation, à l'exportation, ou d'écrire une classe avec un datetime. Je pense que SQL Server a beaucoup de fonctionnalités intégrées permettant de manipuler et de les comparer datetimes pour la plupart des besoins.
    • bien sûr, le choix de la façon de représenter date/temps dépend de beaucoup de choses. Si la date de comparaisons, de l'arithmétique, ou le tri sont pas une évidence pour un ensemble de données particulier, l'application, ou si vous êtes entrer dans un environnement existant qui est déjà normalisé sur une représentation particulière alors il est logique d'aller avec le courant. Pour les nouveaux de développement d'applications, les avantages de représentant de la date/temps à l'interne comme universel, UTC POSIX longs ou Julian Nombre de Jour peut être intéressante et mérite considération. Cette question parle à juste un problème avec datetimes.
    • Vous ne devez jamais jeter une colonne dans la where clause, car il va perdre tout l'indexation dont il dispose. C'est vraiment un mauvais modèle.
    • Premier est la solution parfaite pour la dynamique de la date d'entrées.Merci beaucoup.
    • que faire si la date est la date du dernier jour du mois? comment puis-je avoir une solution générique pour chaque jour de l'année?
    • Vous avez des commentaires précis ne s'applique pas à un casting pour une date en SQL Server.
    • Si vous avez une question, posez une question, pas un commentaire.

    InformationsquelleAutor Gordon Linoff
  2. 37

    Il a été supposé que la deuxième date de référence dans le BETWEEN syntaxe est comme par magie considérée comme la "fin de journée", mais c'est faux.

    c'est à dire ce qui était attendu:

    SÉLECTIONNEZ * à PARTIR de Cas 
OÙ created_at ENTRE début '2013-05-01' ET fin '2013-05-01'

    mais ce qui arrive est-ce:

    SÉLECTIONNEZ * à PARTIR de Cas 
OÙ created_at ENTRE " 2013-05-01 00:00:00+00000' ET '2013-05-01 00:00:00+00000'

    Qui devient l'équivalent d':

    SÉLECTIONNEZ * à PARTIR de Cas OÙ created_at = '2013-05-01 00:00:00+00000'

    Le problème, c'est l'une des perceptions et des attentes à propos de BETWEEN qui ne comprennent à la FOIS la valeur inférieure et la partie supérieure des valeurs dans la plage, mais ne pas comme par magie faire un jour le "début" ou "fin".

    BETWEEN doit être évité lors de filtrage par des plages de dates.

    Toujours utiliser le >= AND < au lieu 

    SÉLECTIONNEZ * à PARTIR de Cas 
OÙ (created_at >= '20130501' ET created_at < '20130502')

    les parenthèses sont facultatives ici, mais peut être important dans des requêtes plus complexes.

    • Des doutes sur la sagesse de l'affichage de ce bien après que la question a déjà été répondu, mais je voulais souligner un point légèrement différent
    • Pour les éditeurs; merci de ne pas essayer de faire de la pseudo-SQL dans les blocs de code, il ne fonctionne tout simplement pas que le commentaire s'appuie sur GRAS.
    • Pour les éditeurs (encore une fois) s'il vous plaît, ne pas ajouter de fausses guillemets par le pseudo-code; ils n'aident PAS à la compréhension.
    InformationsquelleAutor Used_By_Already
  3. 15

    Vous avez besoin de faire l'une de ces deux options:

    1. Inclure le composant dans votre between condition: ... where created_at between '2013-05-01 00:00:00' and '2013-05-01 23:59:59' (non recommandé... voir le dernier paragraphe)
    2. Utiliser les inégalités au lieu de between. Notez que vous devrez ensuite ajouter un jour à la deuxième valeur: ... where (created_at >= '2013-05-01' and created_at < '2013-05-02')

    Ma préférence personnelle est la deuxième option. Aussi, Aaron Bertrand a une explication très claire sur pourquoi il doit être utilisé.

    • +1 pour 2. Mais -1 pour 1. Cette fin de journée hack est totalement fiable et une mauvaise idée.
    • Je préfère aussi l'option 2 (je l'utilise souvent). Mais pourquoi dites-vous que l'option 1 est "totalement non fiable"?
    • veuillez lire ceci en plein. Vous ne devez jamais utiliser BETWEEN pour la plage de dates des requêtes incluant des temps; trop beaucoup de choses peuvent mal se passer.
    InformationsquelleAutor Barranka
  4. 5

    Suffit d'utiliser l'horodatage date:

    SELECT * FROM Cases WHERE date(created_at)='2013-05-01'
    InformationsquelleAutor Balinti
  5. 5

    Je trouve que la meilleure solution pour la comparaison d'un champ de date /heure pour un champ date est le suivant:

    DECLARE @StartDate DATE = '5/1/2013', 
        @EndDate   DATE = '5/1/2013' 

SELECT * 
FROM   cases 
WHERE  Datediff(day, created_at, @StartDate) <= 0 
       AND Datediff(day, created_at, @EndDate) >= 0

    C'est équivalent à un système inclusif entre la déclaration, car elle comprend à la fois le début et date de fin ainsi que ceux qui tombent entre.

    InformationsquelleAutor Ted
  6. 1
    cast(created_at as date)

    Qui fonctionnera qu'en 2008 et les nouvelles versions de SQL Server

    Si vous utilisez une version plus ancienne, puis utiliser 

    convert(varchar, created_at, 101)
    • convert(varchar, created_at, 101) résultat est comme dd/MM/yyyy et OP chaînes sont yyyy-MM-dd, je pense que cette réponse ne fonctionnera pas ;).
    InformationsquelleAutor Ali Adravi
  7. 0

    Vous pouvez utiliser le date() fonction qui va extraire la date à partir d'un datetime et vous donner le résultat sous la forme inclusive date:

    SELECT * FROM Cases WHERE date(created_at)='2013-05-01' AND '2013-05-01'
    InformationsquelleAutor abhishek kumar