2.3Sélection des enregistrements (filtres)
L'essentiel en 30 secondes
- Select Expert = champ + opérateur + valeur : égal, supérieur, entre, contient, dans une liste — combinés en ET/OU.
- Filtrer change aussi les totaux : seuls les enregistrements retenus comptent — le périmètre décide du chiffre.
- Serveur d'abord : conditions simples sur champs de base → WHERE poussé à la base — vérifier via Show SQL Query.
Mini-cas filé — Farès et l'état qui mélangeait deux années
L'état de Farès totalise tout l'historique : la direction veut l'année en cours, région Nord, montants significatifs. Farès ouvre le Select Expert : date de commande entre le 01/01 et le 31/12 ET région = Nord. Les totaux changent aussitôt — normal : le filtre réduit aussi le périmètre des résumés. Puis il vérifie Show SQL Query : la condition figure dans le WHERE, donc la base ne renvoie que l'utile. Il évite le piège inverse : filtrer sur une formule complexe qui aurait rapatrié toute la table avant de trier localement. En 2.4, cette sélection recevra un paramètre année choisi à l'exécution ; en 2.5, la version synthèse reprendra ce périmètre filtré.
Suite du fil rouge 2.2 : les totaux de Farès passent à périmètre filtré — et continue en 2.4 et 2.5.
1. Filtrer avec le Select Expert
Un rapport affiche rarement toutes les données : la sélection des enregistrements (Record Selection) filtre. L'Assistant de sélection (Select Expert) : on choisit un champ, un opérateur (est égal à, est supérieur à, est entre, contient, est dans une liste…) et une valeur. On combine plusieurs conditions (ET/OU). Seuls les enregistrements retenus apparaissent et comptent dans les totaux — filtrer change les résultats. Sous le capot, la sélection devient une formule de sélection (Record Selection Formula), éditable, idéalement convertie en clause WHERE envoyée à la base. Farès filtre : année en cours ET région Nord.
2. Côté serveur vs côté client (performance)
Point CRUCIAL pour la performance : le filtrage côté serveur (la base ne renvoie que le filtré — rapide, léger) contre le filtrage côté client (Crystal rapatrie TOUTES les lignes puis filtre localement — lent et lourd sur de gros volumes). Certaines conditions — formules Crystal complexes, fonctions non traduisibles en SQL — ne peuvent pas être poussées à la base et forcent le filtrage local. La règle : des filtres simples et directs sur les champs de la base restent côté serveur. Farès formule ses conditions sur les champs date et région, pas sur des calculs, pour garder un WHERE efficace.
3. Logique et interactivité
Attention à la logique des conditions combinées : ET restreint (les deux à la fois → moins de résultats), OU élargit (l'un ou l'autre → plus de résultats), et les parenthèses comptent dès qu'on mélange. Pour plusieurs valeurs d'un même champ, préférez « est dans la liste ». On vérifie le SQL généré (« Show SQL Query ») pour confirmer que le filtre est poussé à la base. Et pour un filtre que l'utilisateur choisit à l'exécution (« quelle année ? »), on utilise des paramètres (section 2.4) combinés à la sélection — Farès y viendra pour ne plus modifier le rapport chaque année.
🔎 Exemple concret — 🔎 Exemple concret — Un filtre poussé à la base
L'état de Farès, filtré sur l'année et la région, avec contrôle serveur :
{Commandes.DateCommande} in Date(2026, 1, 1) to Date(2026, 12, 31)
and {Clients.Region} = "Nord"
Show SQL Query → la condition apparaît dans le WHERE : filtrage côté serveur, rapide.Lecture : formule de sélection simple sur champs de base, traduite en WHERE.
Leçon : éviter les formules complexes dans le filtre pour ne pas basculer côté client.
Vocabulaire de la section
- Sélection des enregistrements
- Ne conserver que les enregistrements satisfaisant une condition (année, région, seuil) via le Select Expert ; filtre l'affichage ET les totaux.
Exemple simple : Farès ne garde que les commandes 2026 de la région Nord.
Ce que ce n'est pas : un tri qui ordonne sans exclure.
Réflexe : périmètre voulu = sélection explicite.
- Select Expert
- L'outil de filtrage : champ + opérateur (égal, entre, contient, dans une liste…) + valeur, avec combinaison ET/OU.
Exemple simple : Farès combine date entre deux bornes ET région égale à Nord.
Ce que ce n'est pas : l'éditeur de formules de calcul (niveau 3).
Réflexe : filtrer = champ + opérateur + valeur.
- Formule de sélection
- La traduction du filtre en formule (Record Selection Formula), éditable, idéalement convertie en clause WHERE SQL.
Exemple simple : La sélection de Farès devient une formule sur date et région, visible dans Show SQL Query.
Ce que ce n'est pas : une formule de calcul affichée dans une section.
Réflexe : filtre = formule vérifiable dans le SQL.
- Côté serveur / côté client
- Serveur : la base filtre via WHERE (rapide) ; client : Crystal rapatrie tout puis filtre localement (lent sur gros volumes).
Exemple simple : Le filtre simple de Farès reste serveur ; une formule complexe le ferait basculer en local.
Ce que ce n'est pas : deux façons équivalentes sans impact performance.
Réflexe : simple sur champ de base = serveur.
En pratique — En pratique — Filtrer les enregistrements
- Ouvrez le Select Expert : champ + opérateur (égal, entre, supérieur…) + valeur.
- Combinez plusieurs conditions si besoin (ET/OU) en soignant la logique (ET restreint, OU élargit ; parenthèses).
- Privilégiez des conditions SIMPLES sur les champs de la base pour un filtrage CÔTÉ SERVEUR ; évitez les formules complexes.
- Vérifiez le SQL généré (« Show SQL Query ») ; contrôlez que les totaux reflètent le filtre.
Script prêt à dire — justifier le périmètre filtré (30 s)
« Cet état couvre l'année en cours, région Nord : le filtre exclut le reste, donc les totaux sont à ce périmètre — ce n'est plus le global. Le filtre s'exécute côté base, vérifié dans le SQL : on ne rapatrie que l'utile, c'est rapide même sur l'historique complet. Si vous voulez une autre année, on passera par un paramètre. »
À dire en montrant la formule de sélection de Farès puis le WHERE dans Show SQL Query.
Modèle copier-coller — formules de sélection valides
{Commandes.DateCommande} in Date(2026, 1, 1) to Date(2026, 12, 31)
{Commandes.DateCommande} in Date(2026, 1, 1) to Date(2026, 12, 31) and {Clients.Region} = "Nord"
{Commandes.Montant} > 1000
{Clients.Ville} in ["Alger", "Oran"]Seuil de montant
Farès ne garde que les commandes supérieures à 1 000 : le filtre resserre le périmètre des totaux.
Deux wilayas
Alger OU Oran : Farès utilise « est dans la liste » plutôt qu'un ET impossible sur un même champ.
Filtre qui rame
Filtre posé sur une formule complexe : tout est rapatrié puis trié en local — Farès revient à des champs de base.
Parenthèses oubliées
« A ET B OU C » ambigu : Farès groupe explicitement « (A OU B) ET C » pour le résultat voulu.
✓ Bonnes pratiques
- Formulez des conditions simples sur les champs de base (côté serveur).
- Pour plusieurs valeurs d'un même champ, utilisez « est dans la liste ».
- Vérifiez le WHERE généré pour confirmer le filtrage serveur.
✗ Pièges fréquents
- Filtrer sur une formule complexe : force le filtrage local (lent).
- Confondre ET/OU (« Ville = Alger ET Ville = Oran » ne renvoie rien).
- Mélanger ET/OU sans parenthèses (résultat ambigu).
Points clés à retenir
- Le Select Expert filtre les lignes (champ + opérateur + valeur), combinables (ET/OU). Il filtre l'affichage ET les totaux.
- CRUCIAL : filtrage CÔTÉ SERVEUR (poussé à la base, rapide) vs CÔTÉ CLIENT (tout rapatrié puis filtré, lent).
- Conditions SIMPLES sur les champs de base = côté serveur ; les formules complexes forcent le local. Vérifier « Show SQL Query ».
- Attention à la LOGIQUE (ET restreint, OU élargit ; parenthèses). Pour un filtre choisi à l'exécution, utiliser des PARAMÈTRES (2-4).
Défi 48h — appliquez demain
Sur votre état réel : posez un filtre à 2 conditions (période ET catégorie), vérifiez le WHERE dans Show SQL Query, testez un « dans la liste », puis relisez vos totaux au nouveau périmètre.
- Je peux filtrer (champ + opérateur + valeur, ET/OU) via le Select Expert.
- Je sais garder le filtre côté serveur (conditions simples, WHERE vérifié).
- Je relis mes totaux au périmètre filtré.
Questions fréquentes
Pourquoi le filtrage côté serveur, et comment s'en assurer ?
Côté serveur, la condition est traduite en WHERE SQL et exécutée par la base, qui ne renvoie que les enregistrements utiles : rapide, léger. Côté client, Crystal rapatrie TOUTES les lignes puis filtre localement — catastrophique sur de gros volumes (temps, mémoire, réseau). Ce qui empêche le côté serveur : des filtres sur des formules Crystal complexes ou des fonctions non traduisibles. Pour garantir le côté serveur : formulez des conditions simples et directes sur les champs de la base (Date entre X et Y, Région = « Nord »), évitez de filtrer sur des champs de formule, et VÉRIFIEZ « Show SQL Query » — si votre condition est dans le WHERE, elle est poussée à la base. C'est un levier majeur de performance.
Comment combiner ET/OU sans se tromper ?
ET restreint (toutes les conditions requises → moins de résultats) ; OU élargit (au moins une → plus de résultats). Pièges : (1) confondre ET/OU — « Ville = Alger ET Ville = Oran » ne renvoie rien (une ville ne peut être les deux) ; il fallait OU, ou mieux « est dans la liste [Alger, Oran] » ; (2) mélanger ET/OU sans parenthèses (« A ET B OU C » est ambigu). Raisonnez en langage clair, groupez avec des parenthèses explicites « (Région = Nord OU Région = Sud) ET Montant > 1000 », préférez « dans la liste » pour des valeurs alternatives, et testez le nombre de résultats.
Quel filtrage privilégier pour la performance ?