4.1Sous-rapports (subreports) liés & non liés
Le niveau 4 ouvre les fonctionnalités EXPERTES. Première d'entre elles : les SOUS-RAPPORTS (Subreports) — un rapport INSÉRÉ à l'intérieur d'un autre rapport (le rapport « principal »). Un sous-rapport est un rapport COMPLET à part entière (avec sa propre source, ses champs, sa mise en forme) qui s'affiche dans une section du rapport principal. À quoi ça sert ? Principalement à combiner des données qui ne se prêtent PAS à une simple jointure : (1) des données de SOURCES DIFFÉRENTES (le rapport principal sur une base, le sous-rapport sur une autre base ou un fichier) ; (2) des relations COMPLEXES ou « un-à-plusieurs » difficiles à gérer par jointure sans doublons ; (3) afficher des informations connexes (pour chaque client du rapport principal, afficher ses dernières factures via un sous-rapport). Le sous-rapport apporte de la SOUPLESSE là où les jointures classiques atteignent leurs limites.
La distinction CLÉ : sous-rapport LIÉ vs NON LIÉ. (1) Un sous-rapport NON LIÉ (unlinked) est indépendant : il affiche les MÊMES données quelle que soit sa position dans le principal (par exemple, un récapitulatif global affiché une fois). (2) Un sous-rapport LIÉ (linked) est CONNECTÉ au rapport principal par un CHAMP DE LIEN : pour chaque enregistrement (ou groupe) du principal, le sous-rapport affiche les données CORRESPONDANTES. Exemple : le principal liste les clients ; pour CHAQUE client, un sous-rapport lié (sur le champ ID client) affiche les commandes de CE client. Le sous-rapport se ré-exécute pour chaque valeur de lien — c'est puissant mais peut être COÛTEUX en performance (le sous-rapport lié s'exécute une fois par enregistrement/groupe du principal). Points importants. (1) Un sous-rapport combine des données difficiles à joindre (sources différentes, relations complexes) — sa force principale. (2) LIÉ (données correspondantes par champ de lien, ré-exécuté par enregistrement) vs NON LIÉ (mêmes données, indépendant) : distinction fondamentale. (3) PERFORMANCE : un sous-rapport lié placé dans la section Détails s'exécute pour CHAQUE ligne — très coûteux sur de gros volumes ; le placer plutôt dans un en-tête/pied de GROUPE (une fois par groupe) limite les exécutions. (4) On insère un sous-rapport via « Insérer → Sous-rapport », en créant un nouveau rapport ou en important un existant, puis on définit les LIENS. (5) Les sous-rapports ne partagent pas facilement de données avec le principal (des variables partagées existent, avancé). Maîtriser les sous-rapports — surtout la distinction lié/non lié et l'impact performance — permet de construire des états riches combinant plusieurs sources et relations complexes, là où un rapport simple ne suffit pas.
Vocabulaire de la section
- Sous-rapport (Subreport)
- Un rapport COMPLET inséré à l'intérieur d'un autre (le principal) : sa propre source, ses champs, sa mise en forme, affiché dans une section du principal.
- Usage des sous-rapports
- Combiner des données difficiles à joindre : SOURCES différentes, relations COMPLEXES/un-à-plusieurs, informations connexes (pour chaque client, ses factures) — souplesse là où les jointures atteignent leurs limites.
- Sous-rapport lié (linked)
- Connecté au principal par un CHAMP DE LIEN : pour chaque enregistrement/groupe du principal, il affiche les données CORRESPONDANTES (les commandes de CE client). Ré-exécuté par valeur de lien.
- Sous-rapport non lié (unlinked)
- Indépendant : affiche les MÊMES données quelle que soit sa position (un récapitulatif global affiché une fois).
- Coût performance des sous-rapports liés
- Un sous-rapport lié s'exécute une fois PAR enregistrement/groupe du principal — très coûteux dans la section Détails ; le placer dans un en-tête/pied de GROUPE limite les exécutions.
Qu'est-ce qu'un sous-rapport LIÉ, et quel est le piège de performance ?
En pratique — Insérer un sous-rapport
- Insérez un sous-rapport (« Insérer → Sous-rapport ») : créez un nouveau rapport ou importez-en un existant, avec sa propre source et ses champs.
- Décidez LIÉ ou NON LIÉ : non lié pour un récapitulatif global (mêmes données) ; lié pour des données correspondantes par enregistrement/groupe.
- Pour un sous-rapport LIÉ, définissez le CHAMP DE LIEN (ex. ID client) : il affichera les données correspondant à chaque valeur du principal.
- Pour la PERFORMANCE, placez un sous-rapport lié dans un en-tête/pied de GROUPE (une fois par groupe) plutôt que dans Détails (une fois par ligne).
Points clés à retenir
- Un SOUS-RAPPORT est un rapport COMPLET inséré dans un autre (le principal). Force principale : combiner des données difficiles à JOINDRE — sources différentes, relations complexes/un-à-plusieurs, informations connexes.
- Distinction CLÉ : LIÉ (connecté par un CHAMP DE LIEN — affiche les données correspondant à chaque enregistrement/groupe du principal, ex. les commandes de CE client) vs NON LIÉ (indépendant, mêmes données, ex. un récap global).
- PERFORMANCE : un sous-rapport lié s'exécute une fois PAR enregistrement/groupe du principal. Dans la section DÉTAILS = très coûteux (une exécution par ligne) ; le placer dans un en-tête/pied de GROUPE limite les exécutions.
- On l'insère via « Insérer → Sous-rapport » puis on définit les LIENS. Les sous-rapports partagent difficilement des données avec le principal (variables partagées = avancé). Un outil pour des états riches multi-sources.
Questions fréquentes
Quand utiliser un sous-rapport plutôt qu'une jointure, et comment éviter les problèmes de performance ?
Le sous-rapport et la jointure combinent tous deux des données, mais le sous-rapport résout des cas que la jointure ne gère pas bien — au prix d'un coût de performance qu'il faut maîtriser. Quand une JOINTURE suffit (à privilégier) : quand les tables sont dans la MÊME base et se relient proprement par une clé, une jointure (niveau 0) est plus SIMPLE et plus PERFORMANTE : la base combine les données en une seule requête. Utilisez une jointure chaque fois que c'est possible — c'est la solution par défaut pour combiner des tables reliées. Quand utiliser un SOUS-RAPPORT (les cas où la jointure ne convient pas) : (1) Sources DIFFÉRENTES. Le rapport principal vient d'une base, mais vous devez afficher des données d'une AUTRE base ou d'un fichier (Excel) qui ne peut pas être jointe à la première. Le sous-rapport, ayant sa propre source, le permet. (2) Relations COMPLEXES ou multiples « un-à-plusieurs ». Quand joindre plusieurs relations un-à-plusieurs dans un seul rapport créerait des DOUBLONS et gonflerait les totaux (ex. afficher à la fois les commandes ET les paiements d'un client — deux relations un-à-plusieurs), un sous-rapport isole chaque relation et évite la multiplication des lignes. (3) Données CONNEXES affichées séparément. Pour chaque enregistrement du principal, montrer un bloc d'informations liées (les dernières factures d'un client, l'historique) dans une présentation propre. (4) Logique ou agrégation INDÉPENDANTE difficile à intégrer au principal. En résumé : jointure pour les tables reliées de la même base (par défaut) ; sous-rapport pour les sources différentes, les relations multiples qui créeraient des doublons, ou les données connexes à présenter à part. Comment éviter les problèmes de PERFORMANCE (le point crucial) : un sous-rapport LIÉ se RÉ-EXÉCUTE pour CHAQUE valeur de lien du principal — c'est là que les performances peuvent s'effondrer. (1) NE placez PAS un sous-rapport lié dans la section DÉTAILS si le principal a beaucoup de lignes : il s'exécuterait une fois PAR LIGNE (des milliers d'exécutions = très lent). C'est l'erreur de performance n°1 avec les sous-rapports. (2) Placez-le plutôt dans un EN-TÊTE ou PIED de GROUPE : il s'exécute alors une fois par GROUPE (par client, par catégorie) — bien moins d'exécutions. Regroupez le principal et mettez le sous-rapport au niveau du groupe. (3) LIMITEZ les données du sous-rapport : filtrez-le (côté serveur), n'y mettez que les champs nécessaires — chaque exécution doit être légère. (4) ÉVITEZ les sous-rapports imbriqués ou en cascade (un sous-rapport dans un sous-rapport) : le coût se multiplie. (5) Envisagez des ALTERNATIVES : parfois une jointure bien pensée, une commande SQL (niveau 4-4) ou une vue de base de données évite le sous-rapport et ses coûts. (6) TESTEZ sur un volume réaliste : un sous-rapport peut sembler rapide sur peu de données et devenir inutilisable en production. En résumé : utilisez une JOINTURE quand les tables reliées sont dans la même base (par défaut, plus performant) ; réservez le SOUS-RAPPORT aux cas où la jointure ne convient pas — sources différentes, relations multiples qui créeraient des doublons, données connexes à présenter séparément. Pour la performance, ne mettez JAMAIS un sous-rapport lié dans les Détails d'un gros rapport (une exécution par ligne) : placez-le dans un en-tête/pied de GROUPE (une par groupe), filtrez-le, allégez-le, et testez sur un volume réel. Les sous-rapports sont puissants pour des états riches multi-sources, mais leur coût exige de bien choisir leur emplacement et leur portée.
Comment faire correspondre les données d'un sous-rapport à chaque enregistrement du rapport principal ?
Faire correspondre les données consiste à LIER le sous-rapport au rapport principal par un CHAMP commun, de sorte que le sous-rapport affiche, pour chaque enregistrement/groupe du principal, les données qui lui correspondent — c'est le principe du sous-rapport LIÉ. Le mécanisme du lien : (1) Le rapport principal parcourt ses enregistrements (ou groupes). Pour chacun, il exécute le sous-rapport en lui passant une VALEUR DE LIEN (un champ, typiquement une clé : l'ID client). (2) Le sous-rapport utilise cette valeur pour FILTRER ses propres données : il n'affiche que les enregistrements dont le champ correspond à la valeur reçue. (3) Résultat : pour le client A dans le principal, le sous-rapport montre les commandes du client A ; pour le client B, celles du client B. Les données « suivent » l'enregistrement principal. Comment définir le lien : (1) Insérez le sous-rapport (« Insérer → Sous-rapport ») avec sa source et ses champs (par exemple, un sous-rapport sur la table Commandes). (2) Dans l'onglet/l'étape « LIENS » (Subreport Links), CHOISISSEZ le champ du rapport PRINCIPAL qui sert de lien (ex. Client.ID). (3) Crystal Reports crée un PARAMÈTRE dans le sous-rapport (une valeur reçue) et propose de l'utiliser pour filtrer : indiquez à quel CHAMP du sous-rapport il correspond (ex. Commandes.ClientID). (4) Le sous-rapport est alors filtré automatiquement : « Commandes.ClientID = valeur reçue du principal ». (5) À l'exécution, pour chaque enregistrement/groupe du principal, le sous-rapport affiche les commandes correspondantes. Les points importants : (1) Le champ de lien doit exister des DEUX côtés : une clé commune (ID client dans le principal ET dans le sous-rapport). C'est la correspondance qui fait le filtre. (2) Le filtrage se fait via le paramètre de lien : Crystal l'applique à la sélection du sous-rapport ; idéalement, ce filtre est poussé CÔTÉ SERVEUR (le sous-rapport ne rapatrie que les données correspondantes, pas tout). (3) L'EMPLACEMENT détermine la fréquence : dans les Détails, le sous-rapport lié s'exécute par LIGNE ; dans un en-tête/pied de GROUPE, une fois par GROUPE (préférable pour la performance). (4) Un sous-rapport peut avoir PLUSIEURS liens (plusieurs champs de correspondance) si nécessaire (ex. lier par client ET par année). (5) Vérifiez la correspondance en aperçu : le sous-rapport montre-t-il bien les données du bon enregistrement principal ? Les pièges : (1) Oublier de définir le lien → le sous-rapport affiche TOUTES ses données (non lié) au lieu des données correspondantes. (2) Lier sur le mauvais champ → correspondance fausse. (3) Placer le sous-rapport lié dans les Détails d'un gros rapport → performance catastrophique (voir la question sur la performance). En résumé : faites correspondre les données en LIANT le sous-rapport au principal par un CHAMP commun (une clé, ex. ID client) via l'étape « Liens » : Crystal crée un paramètre qui reçoit la valeur du principal et filtre le sous-rapport dessus (Commandes.ClientID = valeur reçue). Pour chaque enregistrement/groupe du principal, le sous-rapport affiche alors les données correspondantes. Veillez à ce que le champ de lien existe des deux côtés, à ce que le filtre reste côté serveur, et placez le sous-rapport au niveau d'un GROUPE (pas des Détails) pour la performance. Le sous-rapport lié est ce qui permet d'afficher des données connexes contextualisées (les commandes de chaque client) — un mécanisme puissant pour des états riches.