Récupérer la date sans heure depuis un DateTime

Bonjour

J'ai une table avec des dates de type "datetime"

Je doit faire un rapport avec SQL REPORTING SERVICE.

Je veux sélectionner uniquement les données de la veille de 0h00 a 23h59.

et je n'y arrive pas

Comme faire ?

Richard

Bonjour,

Si vous avez une version supérieure à 2008, vous pouvez caster votre colonne en DATE afin de tronquer l'heure.

Merci aieeeuuuuu, mais vous pouvez me donner plus de precisions ?

Il s'agit de Visual studio 2010 avec Windows server 2012R2

Voici le requete généré par le "concepteur de requete" :

Code:

---

1 2 3 4 5 6

SELECT STOC_PF.NUMERO_OF, STOC_PF.CODE_ARTICLE, OF_PRINC.LIBELLE_ARTICLE, STOC_PF.ETAT_STOCK, STOC_PF.QUANTITE_ENTREE, STOC_PF.DATE_ENTREE, STOC_PF.QUANTITE_SORTIE, STOC_PF.DATE_SORTIE, STOC_PF.CODE_MAGASIN, MAGSTOCK.LIBELLE_MAG_PRODUIT_FINI, STOC_PF.NUMERO_COMMANDE, STOC_PF.NUMERO_PALETTE FROM MAGSTOCK INNER JOIN STOC_PF ON MAGSTOCK.NUMERO_MAG_PRODUIT_FINI = STOC_PF.CODE_MAGASIN INNER JOIN OF_PRINC ON STOC_PF.NUMERO_OF = OF_PRINC.NUMERO_OF WHERE STOC_PF.DATE_ENTREE ????

---

Au final je ne veux que les données de la veille de 0h00 a 23h59

Richard

J'ai essayé

Code:

---

WHERE CONVERT(102,DATEADD(day,1,STOC_PF.DATE_ENTREE)) = CONVERT(102,GETDATE())

---

mais ca ne marche pas.

essayez comme ceci :

Code:

---

1 2	WHERE CAST(STOC_PF.DATE_ENTREE AS DATE) = CAST(DATEADD(day,-1,GETDATE()) AS DATE)

---

Whaou ! merci, ça fonctionne parfaitement.

Richard

Bonjour,

Le filtre exprimé précédemment est correct, mais il n'est pas cherchable. Il vaut mieux donc écrire :

Code:

---

1 2	WHERE STOC_PF.DATE_ENTREE >= CAST(CAST(CAST(DATEADD(day, -1, GETDATE()) AS float) AS int) AS datetime) -- hier à minuit AND STOC_PF.DATE_ENTREE < CAST(CAST(CAST(GETDATE() AS float) AS int) AS datetime) -- aujourd'hui à minuit

---

@++ ;)

Citation:

---

Envoyé par elsuket

mais il n'est pas cherchable.

---

Si, il l'est dans ce cas précis, avec une colonne de type DATETIME ou DATETIME2 transtypée en DATE. (c'est d’ailleurs pour cela que j'ai déplacé le DATEADD de la requete initiale sur le GETDATE et non sur la colonne)

et c'est quand même plus court à écrire.

Mais en effet, il faut prendre garde aux CAST dans les prédicats, car ce ne sera pas cherchable avec d'autres types de données.

Citation:

---

Envoyé par aieeeuuuuu

Si, il l'est dans ce cas précis, avec une colonne de type DATETIME ou DATETIME2 transtypée en DATE. (c'est d’ailleurs pour cela que j'ai déplacé le DATEADD de la requete initiale sur le GETDATE et non sur la colonne)

---

Oui, tu as tout à fait raison sur le caractère S-ARG ; les 2 requêtes SQL effectuent bien une opération "Index Seek"

Je voulais toutefois souligner que les 2 requête SQL, celle de elsuket et la tienne, ne génèrent pas tout à fait le même plan d'exécution. Certes les 2 requêtes effectuent bien une opération "Index Seek", mais dans ta formulation, l'index a été utilisé au prix d'une légère transformation du prédicat par l'optimiseur, alors que dans la formation de la requête par elsuket le plan d'exécution est plus compact et contient 3 opérations en moins ("Constant Scan", "Comput Scalar" et "Nested loops (Inner Join)").

Ci-dessous quelques comparatifs

Requête elsuket
Il n'y a pas eu de transformation du prédicat :

Code:

---

1 2 3

Seek Predicate Début : STOC_PF.DATE_ENTREE >= Opérateur scalaire(CONVERT(datetime,CONVERT(int,CONVERT(float(53),dateadd(day,(-1),getdate()),0),0),0)); Fin : STOC_PF.DATE_ENTREE < Opérateur scalaire(CONVERT(datetime,CONVERT(int,CONVERT(float(53),getdate(),0),0),0))

---

Plan d'exécution :
Pièce jointe 193815


Requête aieeeuuuuu
Le prédicat a été légèrement transformé par l'optimiseur, et ce, pour pouvoir utiliser l'index (Voir ci-dessous la transformation dans "Seek predicate")

Code:

---

1 2 3 4 5

Predicates CONVERT(date,STOC_PF.DATE_ENTREE ,0)=CONVERT(date,dateadd(day,(-1),getdate()),0) Seek Predicate Début : STOC_PF.DATE_ENTREE > Opérateur scalaire([Expr1007]); Fin : STOC_PF.DATE_ENTREE < Opérateur scalaire([Expr1008])

---

Plan d'exécution :
Pièce jointe 193814


Sinon les différences au niveau coût, sont en faveur de la formulation d'elsuket, mais restent très négligeables selon le scénario de mes tests, effectué sur une table contenant 22000 lignes.
A+,

Pour aller juste un peu plus loin c'est effectivement une transformation cachée opérée par l'optimiseur avec l'utilisation d'une fonction GetRangeThroughConvert() dont le rôle est de déterminer le domaine de valeurs DATETIME2 couverte par la variable @1 et qui est utilisée dans le cadre d'une recherche dynamique avec un coût supplémentaire mais négligeable ici.

Code:

---

GetRangeThroughConvert(CONVERT_IMPLICIT(date,[@1],0),CONVERT_IMPLICIT(date,[@1],0),(62))

---

L'idée étant de pouvoir utiliser un potentiel index comme vu plus haut

++