Comparaison de DATETIME : ignorer les ms

**Pfeffer** · 02/07/2021, 10h47

Bonjour à tous,

J'ai un sérieux problème avec une requête qui au premier jet, me remonte fréquemment un Timeout.
Je pense que le problème vient dette clause WHERE:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
WHERE CONVERT (DATETIME, CONVERT (VARCHAR, c.dateversion, 120), 120)

En fait ce que je fais, c'est une comparaison sur un DATETIME mais je supprime ou ignore les millisecondes.
Donc comme je disais, la première fois c'est extrêmement long à charger, et ensuite je pense que le plan d'exécution est dans le cash ou quelque chose du genre, mais la réponse est instannée.

Une idée ? Comment je peux faire mieux ?

**tatayo** · 02/07/2021, 11h01

Bonjour,
A moins d'une erreur de copier/coller, je ne vois pas de comparaison dans le code que tu nous affiches, seulement une double conversion.

Tatayo.

**Pfeffer** · 02/07/2021, 11h33

Oui, vous avez raison, j'ai pas tout copier / coller.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
 
WHERE CONVERT (DATETIME, CONVERT (VARCHAR, c.dateversion, 120), 120) > '01/07/2021 07:00:08'

**tatayo** · 02/07/2021, 11h46

Comme tu appliques une fonction sur la colonne de la table, aucun index n'est utilisable.
Donc s'il n'y a aucun autre critère, SqlServer va parcourir toute la table pour retrouver ses petits.
Lors du deuxième appel, tout est dans le cache, donc l'accès est bien plus rapide.

Par contre je ne comprends pas cette double conversion.
Quel est le type de la colonne DateVersion ?
Si c'est un DateTime, pourquoi faire une conversion en Varchar, puis en DateTime ?

Tatayo.

**Pfeffer** · 02/07/2021, 14h16

Excellente question ... J'ai trouvé cette parade sur le net, je l'avoue j'ai vu que ça machait, mais j'ai pas regardé davantage la solution proposée.
Et comme d'habitude il faut allet vite ...
Je comprends tout à fait le pb des index ! Il va falloir que je trouve une meilleure solution alors ...
Il s'agit bien d'un DATETIME !!