[SQL Server 2000] Extraction des trimestres

Bonjour,

Bon ce doit être idiot mais je n'arrive pas à extraire les trimestres.

Le champs date est de type DateTime (Ce serait ça le problème).

Donc j'ai ceci :

Code:

---

DATEPART("q", ChampsDate)

---

et j'ai essayé :

Code:

---

DATEPART("t", ChampsDate)

---

Et il me réponds

Citation:

---

Invalid parameter 1 specified for datepart

---

Cela marche avec tous les autres intervalles...

Salut !

Qu'est ce que tu entends par trimestre ?
C'est le nombre que tu obtiens quand tu divises le numéro de mois par 3 ?
(bon, faut quand même prendre la partie entière supérieure...)

(Si oui, la réponse est donnée ;))

Salut chose des abysses

Essaye...

Code:

---

DATEPART(q,LaDate)

---

+++

C'est que je pensais qu'il faisait ça tout seul, d'après les tutoriels cela semblait possible.

J'avais bien vu les possibilités pour les semestre en ajoutant des calculs mais bon.

Je vais essayer le CASE, ça n'est pas très beau mais au moins je suis sur que ça fonctionnera, merci...

Salut elbj, nouvelle créature des abyss,

Déjà merci à pacmann pour sa réponse.

Et bravo elbj, comme quoi c'est bien ce que je disais c'est un truc idiot, j'ai même pas pensé à essayer sans les simples et doubles quotes...(Sinon le CASE fonctionne aussi mais c'est barbar)

LA HONTE :oops:

THANKS :king:

De rien...

Il me semble que, dans la mesure du possible, il faut éviter les CASE dans une requête car ça rompt le traitement ensembliste pour forcer un traitement séquentiel.

Je viens peut-être de dire une grosse bêtise, peut-être que si un spécialiste passe par là...

+++

Je ne suis pas un spécialiste, mais il me semble que le case doit être évité lorsqu'il est possible de séparer les cas dans le WHERE.

Par exemple, la grosse caricature :

Code:

---

1 2 3

SELECT case when id > 1000 then 'a' else 'b' end FROM T

---

(avec id indexée)
=> c'est très séquentiel

Code:

---

1 2 3 4 5 6 7 8

SELECT 'a' FROM T WHERE id >1000 UNION ALL SELECT 'b' FROM T WHERE id <=1000

---

=> là, c'est plus rapide. Normal

Par contre, si tu dois appliquer une fonction, le traitement sera séquentiel qu'il s'agisse d'un case, ou d'opérations en tous genres...

EDIT :
Bon, après, il y a peut être une différence légère de vitesse d'exécution entre certaines instruction et d'autres.
Encore une fois, une caricature :
- d'un côté, un bitshift
- de l'autre, des recherches sur chaînes de caractères imbriquées avec des remplacements et des comparaisons, finissant par des casts...

Bonsoir

Il est clair que l'utilisation de fonctions dans les requêtes casse l'approche ensembliste de celles-ci. A éviter autant que faire se peut.

Cordialement

Pour le CASE, tout dépend du moteur de bases de données.

Si CASE valué avec en expression une seule colonne, alors il est optimisable (et systématiquement optimisé par SQL Server par exemple).

Exemple :

Code:

---

1 2 3 4 5 6 7 8 9

SELECT ... FROM ...   WHERE CASE colonne1 WHEN 1 THEN 'toto' WHEN 2 THEN 'titi' WHEN 3 THEN 'tata' ELSE 'zut' END = colonne2

---

Si CASE généralisé, alors il est aussi optimisable si le prédicat est "sargable".
Exemple :

Code:

---

1 2 3 4 5 6 7 8 9

SELECT ... FROM ...   WHERE CASE WHEN colonne1 = 1 THEN 'toto' WHEN colonne2 BETWEEN 5 AND 999 THEN 'titi' WHEN LOG(SIN(colonne16)) = .01253 THEN 'tata' ELSE 'zut' END = colonne2

---

Peut être optimisé pour les colonnes colonne1 et colonne2 puisque c'est dans l'ordre de lecture que se fait l'application du CASE. Autrement dit il est important que des expressions "sargable" figurent dans les premières branches du CASE.

A +

Merci,

Par contre j'ai du faire une bêtise car je l'ai utilisé dans le SELECT. Cela fait-il une grosse différence de traitement.

Citation:

---

Je ne suis pas un spécialiste, mais il me semble que le case doit être évité lorsqu'il est possible de séparer les cas dans le WHERE.

---

Est-ce une bonne solution d'utiliser le CASE en fait ou y'a-t-il des moyens de l'éviter ?