4.1Sous-rapports (liés & non liés)
L'essentiel en 30 secondes
- Un sous-rapport = un rapport complet dans le principal : sa propre source, ses champs, sa mise en forme — la solution quand une simple jointure ne suffit pas (sources différentes, relations un-à-plusieurs multiples).
- Lié ou non lié, tout change : non lié = mêmes données affichées une fois (récap global) ; lié = données correspondantes par champ de lien, ré-exécuté pour chaque valeur du principal.
- Réflexe de Farès : un sous-rapport lié se place au niveau d'un groupe (une exécution par groupe), jamais dans les Détails d'un gros rapport — et on préfère la jointure quand les tables sont dans la même base.
Mini-cas filé — Farès et le relevé client avec factures
Farès, contrôleur de gestion à Alger, doit produire le relevé mensuel des clients : le rapport principal liste les clients depuis la base de gestion, mais les factures détaillées viennent d'une autre extraction que la jointure gonflerait en doublons (deux relations un-à-plusieurs : commandes ET paiements). Il insère un sous-rapport lié sur l'ID client, placé dans l'en-tête de groupe Client : pour chaque client, le sous-rapport affiche les factures de CE client, une seule exécution par client. Premier jalon du fil rouge : Farès combine deux sources sans doublons et sans tuer la performance.
Ce même cas revient dans le cours, le schéma, le script et le défi 48h — et continue en 4.2, 4.3, 4.4 et 4.5.
1. Un rapport dans un rapport : quand le sous-rapport s'impose
Le niveau 4 ouvre les fonctionnalités expertes. Première d'entre elles : les sous-rapports (Subreports) — un rapport complet (sa propre source, ses champs, sa mise en forme) inséré dans une section du rapport « principal ». Comme pour le relevé de Farès, sa force est de combiner des données qui ne se prêtent PAS à une simple jointure : sources différentes (deux bases, une base + un fichier), relations complexes ou un-à-plusieurs multiples qui créeraient des doublons, informations connexes à présenter à part (pour chaque client, ses dernières factures).
Règle de décision : quand les tables sont dans la même base et se relient proprement par une clé, une jointure reste plus simple et plus performante — c'est le choix par défaut. Le sous-rapport est l'outil des cas où la jointure ne convient pas : sources non jointables, doublons de jointure, logique ou agrégation indépendante. On l'insère via « Insérer → Sous-rapport » (nouveau rapport ou import d'un existant), puis on définit les liens.
2. Lié vs non lié : le champ de lien fait tout
Distinction clé. Un sous-rapport non lié (unlinked) est indépendant : il affiche les mêmes données quelle que soit sa position — par exemple un récapitulatif global affiché une fois dans un pied de rapport. Un sous-rapport lié (linked) est connecté au principal par un champ de lien : pour chaque enregistrement ou groupe du principal, il affiche les données correspondantes — les commandes de CE client, comme les factures de chaque client de Farès.
Mécanisme : dans l'étape « Liens » (Subreport Links), on choisit le champ du principal (ex. Client.ID) ; Crystal Reports crée un paramètre dans le sous-rapport et l'associe au champ correspondant (ex. Factures.ClientID) — le filtre s'applique automatiquement, idéalement côté serveur. Le champ de lien doit exister des deux côtés. Piège classique : oublier le lien — le sous-rapport affiche alors toutes ses données, comme un non lié.
3. La performance : l'emplacement décide du coût
Un sous-rapport lié se ré-exécute pour chaque valeur de lien du principal. Placé dans la section Détails, il s'exécute une fois PAR ligne — catastrophique sur gros volumes. Placé dans un en-tête ou pied de groupe, il ne s'exécute qu'une fois par groupe — c'est le geste de Farès : une exécution par client au lieu d'une par facture.
Compléments de prudence : limiter les données du sous-rapport (filtre côté serveur, champs utiles uniquement), éviter les sous-rapports imbriqués (coût multiplié), envisager une alternative (jointure, commande SQL en 4.4, vue consolidée) et tester sur un volume réel. Les sous-rapports partagent difficilement des données avec le principal (variables partagées = avancé).
🔎 Exemple concret — 🔎 Exemple concret — Les factures de chaque client
Le relevé de Farès : un principal clients, un sous-rapport factures lié et bien placé.
Principal : liste des clients (groupé par client).
Sous-rapport lié sur ID client → les factures de CE client.
Placé dans l'EN-TÊTE DE GROUPE (une exécution par client, pas par ligne).Lecture : lier par la clé commune, filtrer côté serveur, placer au niveau du groupe.
Leçon : des données connexes contextualisées, sans doublons ni effondrement des performances.
Vocabulaire de la section
- Sous-rapport (Subreport)
- Rapport COMPLET inséré dans un autre (le principal) : sa propre source, ses champs, sa mise en forme, affiché dans une section du principal.
Exemple simple : Farès affiche les factures (autre extraction) dans le relevé clients sans les joindre.
Ce que ce n'est pas : une simple section supplémentaire du même rapport.
Réflexe : sources non jointables ou doublons de jointure : penser sous-rapport.
- Sous-rapport lié (linked)
- Connecté au principal par un CHAMP DE LIEN : affiche les données correspondant à chaque enregistrement ou groupe, ré-exécuté par valeur de lien.
Exemple simple : Pour chaque client de Farès, le sous-rapport montre les factures de CE client.
Ce que ce n'est pas : un récap global identique partout.
Réflexe : données correspondantes par enregistrement : définir le lien des deux côtés.
- Sous-rapport non lié (unlinked)
- Indépendant : affiche les MÊMES données quelle que soit sa position dans le principal.
Exemple simple : Farès affiche un récap global des impayés une fois en pied de rapport.
Ce que ce n'est pas : un détail qui suit chaque enregistrement.
Réflexe : récap global affiché une fois : non lié en pied de rapport.
- Coût par exécution
- Un sous-rapport lié s'exécute une fois PAR valeur de lien : Détails = une fois par ligne (coûteux), groupe = une fois par groupe.
Exemple simple : Farès passe de centaines d'exécutions (Détails) à une par client (groupe).
Ce que ce n'est pas : un coût fixe indépendant de l'emplacement.
Réflexe : lié + gros volume : toujours remonter au niveau du groupe.
En pratique — 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 ou 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 ou pied de GROUPE (une fois par groupe) plutôt que dans Détails (une fois par ligne).
Script prêt à dire — justifier le sous-rapport à son responsable (30 s)
« C'est Farès : pour le relevé clients, je ne peux pas joindre les factures sans créer des doublons — j'ai donc mis un sous-rapport lié par l'ID client, placé au niveau du groupe. Une exécution par client au lieu d'une par ligne : le relevé reste juste et s'ouvre en quelques secondes. »
À dire quand on vous demande pourquoi ne pas « simplement joindre » : montrez le total gonflé par les doublons.
Modèle copier-coller — fiche de cadrage d'un sous-rapport
Besoin : [relevé clients + factures autre extraction]
Choix : [jointure impossible → sous-rapport]
Type : [lié sur ID client | non lié — récap global]
Lien : principal [Client.ID] → sous-rapport [Factures.ClientID], filtre côté serveur [oui]
Emplacement : [en-tête de groupe Client — une exécution par client]
Contenu : [champs utiles uniquement : N° facture, date, montant]Relevé client multi-sources
Comme Farès : principal sur la base de gestion, sous-rapport lié sur l'autre extraction — une exécution par client.
Double relation un-à-plusieurs
Commandes ET paiements d'un client : un sous-rapport par relation pour éviter la multiplication des lignes.
Récapitulatif global
Total des impayés affiché une fois en pied de rapport : sous-rapport non lié, sans champ de lien.
Gros volume qui rame
Remonter le sous-rapport au groupe, filtrer côté serveur, envisager une commande SQL ou une vue (voir 4.4).
✓ Bonnes pratiques
- Placez un sous-rapport lié au niveau d'un GROUPE, pas dans les Détails.
- Filtrez le sous-rapport côté serveur et n'y mettez que les champs utiles.
- Privilégiez une jointure quand les tables sont dans la même base.
✗ Pièges fréquents
- Un sous-rapport lié dans les Détails d'un gros rapport (performance catastrophique).
- Oublier le lien (le sous-rapport affiche alors toutes ses données).
- Enchaîner des sous-rapports imbriqués (coût multiplié).
Points clés à retenir
- Un SOUS-RAPPORT est un rapport COMPLET inséré dans un autre. Force : combiner des données difficiles à JOINDRE — sources différentes, relations complexes, informations connexes.
- Distinction CLÉ : LIÉ (champ de lien — données correspondantes par enregistrement/groupe) vs NON LIÉ (indépendant, mêmes données).
- PERFORMANCE : un lié s'exécute une fois PAR valeur de lien. Détails = très coûteux ; en-tête/pied de GROUPE = bien moins d'exécutions.
- Insertion via « Insérer → Sous-rapport » puis définition des LIENS. Tester sur volume réel.
Défi 48h — appliquez demain
Sur un vrai relevé : insérez un sous-rapport lié (clé commune des deux côtés), placez-le au niveau du groupe, limitez ses champs et comparez le temps d'ouverture avec un placement dans les Détails.
- Je sais insérer un sous-rapport et choisir lié ou non lié selon le besoin.
- Je sais définir un champ de lien présent des deux côtés, filtré côté serveur.
- Je place un sous-rapport lié au niveau du groupe et je teste sur volume réel.
Questions fréquentes
Quand utiliser un sous-rapport plutôt qu'une jointure, et comment éviter les problèmes de performance ?
Quand les tables sont dans la MÊME base et se relient par une clé, une JOINTURE est plus simple et plus performante — c'est le choix par défaut. Réservez le SOUS-RAPPORT aux cas où la jointure ne convient pas : sources DIFFÉRENTES non jointables, relations multiples un-à-plusieurs qui créeraient des doublons, données connexes à présenter à part. Performance : un sous-rapport lié se ré-exécute pour chaque valeur de lien — ne le placez JAMAIS dans les Détails d'un gros rapport : mettez-le dans un en-tête ou pied de GROUPE, limitez ses données (filtre côté serveur, champs utiles), évitez les imbriqués, envisagez une commande SQL ou une vue (voir 4.4), et testez sur un volume réel.
Comment faire correspondre les données d'un sous-rapport à chaque enregistrement du rapport principal ?
En LIANT le sous-rapport au principal par un CHAMP commun (ex. ID client). Pour chaque enregistrement ou groupe, le principal passe une valeur de lien et le sous-rapport filtre ses données dessus. Concrètement : insérez le sous-rapport, puis dans l'étape « Liens » choisissez le champ du principal (Client.ID) et associez-le au champ correspondant du sous-rapport (Factures.ClientID) — Crystal Reports crée le paramètre et applique le filtre automatiquement. Points clés : clé présente des DEUX côtés, filtre côté serveur, emplacement (Détails ou groupe) qui règle la fréquence d'exécution. Sans lien, le sous-rapport affiche toutes ses données.
Où placer un sous-rapport lié pour préserver la performance ?