Le filtrage côté serveur est déterminant pour la PERFORMANCE : il fait traiter le filtre par la base de données (qui ne renvoie que les données utiles) au lieu de rapatrier toutes les lignes puis filtrer localement — la différence est énorme sur de gros volumes. Le principe (serveur vs client) : (1) Côté SERVEUR : la condition de sélection est traduite en clause WHERE SQL et ENVOYÉE à la base. La base fait le tri et ne RENVOIE QUE les enregistrements qui passent le filtre. Crystal Reports reçoit peu de données (juste l'utile). Rapide, léger sur le réseau et la mémoire. (2) Côté CLIENT : quand la condition ne peut pas être traduite en SQL, Crystal Reports rapatrie TOUS les enregistrements de la base, puis applique le filtre LOCALEMENT sur le poste. Sur une table de millions de lignes, cela signifie tout transférer et charger avant de jeter la majorité — lent, lourd, parfois bloquant. Pourquoi c'est IMPORTANT : (1) Volume. Sur de petites tables, la différence est négligeable ; sur de GROS volumes, le filtrage client est catastrophique (temps d'exécution, mémoire, réseau saturés). Un rapport qui « rame » vient très souvent d'un filtrage client sur beaucoup de données. (2) Charge. Filtrer côté serveur exploite l'optimisation de la base (index) ; côté client, on n'a aucun de ces avantages. (3) La performance d'un rapport dépend en grande partie de la QUANTITÉ de données rapatriées — et le filtrage serveur la minimise. Ce qui empêche le filtrage serveur : (1) Des conditions basées sur des FORMULES Crystal complexes (qui n'ont pas d'équivalent SQL). (2) Certaines FONCTIONS Crystal non traduisibles. (3) Des filtres portant sur des champs de FORMULE (calculés dans Crystal, pas dans la base). (4) Une logique trop élaborée. Dans ces cas, Crystal bascule en filtrage local. Comment s'assurer d'un filtrage serveur : (1) Formulez des conditions SIMPLES et DIRECTES sur les CHAMPS DE LA BASE (Date entre X et Y, Région = « Nord », Montant > 1000) — ce sont celles qui se traduisent en SQL. (2) ÉVITEZ de filtrer sur des champs de formule ou avec des fonctions Crystal complexes quand c'est possible ; préférez filtrer sur les colonnes brutes. (3) VÉRIFIEZ le SQL généré : « Database → Show SQL Query » montre la requête envoyée à la base ; si votre condition apparaît dans la clause WHERE, elle est poussée au serveur ; si le WHERE est vide alors que vous filtrez, le filtrage est local. C'est le contrôle décisif. (4) Poussez aussi le TRI et les GROUPES côté serveur quand possible (option « Perform Grouping On Server » pour certains cas). (5) Pour les filtres utilisateur, utilisez des PARAMÈTRES intégrés à la formule de sélection de façon à rester traduisibles en SQL. En résumé : le filtrage côté serveur est important car il minimise les données rapatriées (la base filtre et ne renvoie que l'utile), ce qui est déterminant pour la performance sur de gros volumes — le filtrage client (tout rapatrier puis filtrer) est lent et lourd. Pour garantir le côté serveur, écrivez des conditions SIMPLES sur les champs de la BASE (pas sur des formules complexes), et VÉRIFIEZ dans le SQL généré (« Show SQL Query ») que votre filtre apparaît bien dans la clause WHERE. C'est l'un des leviers majeurs de performance d'un rapport Crystal.

Combiner des conditions avec ET (AND) et OU (OR) permet des filtres précis, mais une erreur de logique est facile et donne un rapport avec trop ou trop peu de données — voici comment raisonner juste. Le sens de ET et OU : (1) ET (AND) RESTREINT : un enregistrement doit satisfaire TOUTES les conditions liées par ET pour être gardé. Plus on ajoute de ET, MOINS il reste d'enregistrements. Ex. « Région = Nord ET Montant > 1000 » → seulement les commandes du Nord ET de plus de 1000 (les deux à la fois). (2) OU (OR) ÉLARGIT : un enregistrement est gardé s'il satisfait AU MOINS UNE des conditions liées par OU. Plus on ajoute de OU, PLUS il reste d'enregistrements. Ex. « Région = Nord OU Région = Sud » → les commandes du Nord ou du Sud. Les pièges classiques : (1) Confondre ET et OU. « Les clients de Paris ET de Lyon » : si on écrit « Ville = Paris ET Ville = Lyon », on obtient RIEN (une ville ne peut être Paris ET Lyon en même temps) — il fallait OU (« Ville = Paris OU Ville = Lyon »). Erreur très fréquente : le « et » du langage courant correspond souvent à un OU logique quand il s'agit de valeurs alternatives d'un même champ. Pour ce cas, l'opérateur « est dans la liste » (in) est plus clair : « Ville est dans [Paris, Lyon] ». (2) Mélanger ET et OU sans PARENTHÈSES. « A ET B OU C » est ambigu : est-ce « (A ET B) OU C » ou « A ET (B OU C) » ? Les deux donnent des résultats DIFFÉRENTS. Sans parenthèses, la priorité par défaut (le ET s'évalue avant le OU) peut ne pas correspondre à votre intention. Remède : utilisez des PARENTHÈSES explicites pour grouper les conditions comme vous le voulez. (3) Filtres qui s'excluent : des ET contradictoires donnent zéro résultat ; des OU trop larges ramènent tout. Comment raisonner juste : (1) Formulez le besoin en langage clair puis traduisez : « je veux X et aussi Y (les deux) » → ET ; « je veux X ou bien Y (l'un ou l'autre) » → OU. (2) Pour plusieurs valeurs d'un MÊME champ (plusieurs villes, plusieurs statuts), pensez OU — ou mieux, l'opérateur « est dans la liste » (in) qui est plus lisible et moins piégeux. (3) Groupez avec des PARENTHÈSES dès que vous mélangez ET et OU : « (Région = Nord OU Région = Sud) ET Montant > 1000 » est sans ambiguïté. (4) TESTEZ le résultat : vérifiez le nombre d'enregistrements obtenus — s'il y en a trop, un OU est trop large ou un ET manque ; s'il y en a trop peu (ou zéro), un ET est trop restrictif ou vous avez confondu ET/OU. (5) Au besoin, éditez la FORMULE de sélection directement pour un contrôle total de la logique (avec parenthèses explicites). En résumé : ET RESTREINT (toutes les conditions requises, moins de résultats), OU ÉLARGIT (au moins une, plus de résultats). Les erreurs fréquentes sont de confondre ET/OU (surtout pour plusieurs valeurs d'un même champ — utilisez OU ou « dans la liste ») et de mélanger ET/OU sans parenthèses (ambiguïté). Raisonnez en langage clair, groupez avec des PARENTHÈSES explicites, préférez « dans la liste » pour des valeurs alternatives, et TESTEZ le nombre de résultats. Une logique de filtre correcte est essentielle : un filtre mal combiné produit un rapport avec les mauvaises données, sans erreur visible.