4.4Commandes SQL & rapports multi-sources
L'essentiel en 30 secondes
- La commande SQL = écrire sa propre requête : au lieu de laisser Crystal Reports générer, on écrit SELECT, FROM, WHERE, JOIN — exécutée telle quelle comme une « table virtuelle ».
- Contrôle et performance maximum : jointures exactes, filtres et agrégations poussés côté base — décisif sur gros volumes et pour les requêtes complexes (sous-requêtes, UNION).
- Réflexe de Farès : paramètres Crystal dans la requête pour filtrer côté serveur ; sous-rapports pour les sources différentes — et jamais de credential en dur dans la commande.
Mini-cas filé — Farès et le top clients côté serveur
Farès, contrôleur de gestion à Alger, doit sortir le chiffre d'affaires par client sur l'année choisie : via l'interface, Crystal rapatrie toutes les lignes puis agrège — trop lent sur des centaines de milliers de commandes. Il ajoute une commande SQL qui filtre par année via un paramètre et agrège côté base (GROUP BY), ne rapatriant que les totaux. Pour la deuxième source (un fichier de remises non jointable), il garde un sous-rapport lié (voir 4.1). Quatrième jalon du fil rouge : Farès fait travailler la base, pas le poste client.
Suite des cas 4.1-4.3 — Farès passe du visuel à la performance côté base.
1. La commande SQL : écrire au lieu de cliquer
Pour les besoins avancés, la commande SQL (SQL Command) : au lieu de choisir des tables et de laisser Crystal Reports générer la requête, on écrit sa propre requête (SELECT … FROM … WHERE … JOIN …) qui devient la source du rapport, exécutée telle quelle comme une « table virtuelle ». On l'ajoute dans l'assistant de connexion.
Usages : contrôle total (jointures, filtres, calculs côté base), requêtes complexes impossibles ou pénibles via l'interface (jointures élaborées, sous-requêtes, regroupements SQL, UNION, fonctions spécifiques à la base), performance (pousser le travail vers la base, optimisée pour cela, et ne rapatrier que le résultat). On y intègre des paramètres Crystal pour un filtrage interactif exécuté côté serveur, comme le paramètre année de Farès.
2. Les rapports multi-sources : choisir selon la nature des sources
Combiner plusieurs origines selon le cas. Même base → jointures classiques ou commande SQL (performant : la base combine en une requête). Sources différentes non jointables (deux bases, base + fichier) → sous-rapports (voir 4.1), souvent la meilleure approche : chaque source dans son rapport, lié par un champ commun.
Crystal Reports permet aussi d'ajouter plusieurs connexions dans un même rapport (multi-connexions), mais les jointures inter-sources se font parfois côté client — coûteuses sur volumes importants, à réserver aux petits cas. Pour des combinaisons complexes, récurrentes ou volumineuses, le plus robuste est souvent de consolider en amont (vue de base, table de synthèse, ETL) puis de brancher le rapport sur une source unique.
3. Compétence et maintenance : le prix du contrôle
La commande SQL exige de maîtriser le SQL : la requête doit être valide et optimisée — une mauvaise requête donne un rapport lent ou faux — et c'est du code à maintenir (documenter, versionner), contrairement au glisser-déposer. En cas de doute, commencer par l'interface ; passer à la commande SQL seulement en butant sur une limite.
C'est le niveau où le reporting rejoint la maîtrise des bases de données — puissant, mais exigeant en compétences et en rigueur. Côté sécurité : compte de lecture seule, paramètres plutôt que concaténation, aucun mot de passe en dur (voir prudence ci-dessous).
🔎 Exemple concret — 🔎 Exemple concret — Filtrer côté serveur en SQL
Le top clients de Farès : un paramètre dans la requête, l'agrégation côté base.
SELECT client, SUM(montant) AS total
FROM commandes
WHERE annee = {?Annee}
GROUP BY client
→ La base filtre et agrège ; Crystal reçoit le minimum.Lecture : WHERE paramétré + GROUP BY côté base = seules les totaux transitent.
Leçon : contrôle et performance maximum sur gros volumes — requête valide, optimisée, documentée.
Vocabulaire de la section
- Commande SQL (SQL Command)
- Écrire SA PROPRE requête SQL (SELECT, FROM, WHERE, JOIN) comme source du rapport, exécutée telle quelle par la base.
Exemple simple : Farès écrit le top clients par année au lieu de laisser Crystal générer la requête.
Ce que ce n'est pas : une sélection de tables par glisser-déposer.
Réflexe : limite de l'interface ou lenteur : passer à la commande SQL.
- Filtrage côté serveur
- Paramètres Crystal intégrés à la requête : la base filtre et agrège, Crystal ne reçoit que le résultat nécessaire.
Exemple simple : L'année choisie par Farès filtre dans le WHERE exécuté par la base.
Ce que ce n'est pas : rapatrier toutes les lignes puis filtrer dans le rapport.
Réflexe : gros volume : WHERE paramétré + agrégation côté base.
- Rapports multi-sources
- Combiner plusieurs origines : jointures ou SQL (même base), SOUS-RAPPORTS (sources différentes), multi-connexions (jointures côté client, coûteuses).
Exemple simple : Farès : commande SQL pour la base commandes, sous-rapport pour le fichier de remises.
Ce que ce n'est pas : tout mélanger dans une seule connexion multi-sources sur gros volumes.
Réflexe : sources différentes non jointables : d'abord les sous-rapports.
- Consolidation en amont
- Préparer les données avant Crystal (vue, table de synthèse, ETL) puis brancher le rapport sur une source unique — le plus robuste pour les cas lourds.
Exemple simple : Farès fait créer une vue annuelle des ventes pour les rapports récurrents.
Ce que ce n'est pas : combiner à chaque exécution des volumes hétérogènes côté client.
Réflexe : combinaison complexe ou récurrente : consolider une fois, rapporter souvent.
En pratique — En pratique — Utiliser une commande SQL
- Dans l'assistant de connexion, ajoutez une COMMANDE SQL : écrivez votre requête (SELECT … FROM … JOIN … WHERE …) — elle devient la source du rapport.
- Intégrez des PARAMÈTRES Crystal dans la requête pour un filtrage interactif poussé côté serveur.
- Vérifiez que la requête est VALIDE et OPTIMISÉE (jointures, filtres, agrégations côté base) ; testez le résultat et la performance.
- Pour des sources DIFFÉRENTES non jointables, préférez des SOUS-RAPPORTS (4.1) plutôt que le multi-connexions (jointures côté client coûteuses).
Script prêt à dire — expliquer la commande SQL à la DSI (30 s)
« C'est Farès : pour le top clients annuel, j'ai écrit une commande SQL qui filtre par année et agrège côté base — on ne rapatrie que les totaux au lieu de centaines de milliers de lignes. La requête est testée, documentée, et le rapport tourne avec un compte en lecture seule, sans mot de passe en dur. »
À dire pour faire valider l'accès base : présentez la requête, le compte utilisé et le gain mesuré.
Modèle copier-coller — commande SQL paramétrée (valide)
SELECT c.nom_client AS client,
SUM(l.montant) AS total
FROM clients AS c
INNER JOIN commandes AS l
ON l.id_client = c.id_client
WHERE l.annee = {?Annee}
GROUP BY c.nom_client
ORDER BY total DESCTop clients annuel
Comme Farès : WHERE sur l'année paramétrée + GROUP BY côté base — seuls les totaux transitent.
Requête complexe (UNION)
Combiner deux SELECT compatibles par UNION dans la commande quand l'interface ne le permet pas.
Sources hétérogènes
Base d'un côté, fichier de l'autre : sous-rapport lié plutôt que multi-connexion coûteuse.
Cas récurrent volumineux
Demander une vue ou une table de synthèse en amont : le rapport se branche sur une source unique et rapide.
✓ Bonnes pratiques
- Commencez par l'interface ; passez à la commande SQL si vous butez sur une limite.
- Poussez jointures, filtres et agrégations côté base ; exploitez les index.
- Consolidez en amont (vue, table) pour les combinaisons complexes ou volumineuses.
✗ Pièges fréquents
- Une requête SQL mal écrite (rapport lent ou faux).
- Multi-connexions sur gros volumes (jointures côté client).
- Oublier que la commande SQL est du code à maintenir.
Points clés à retenir
- La COMMANDE SQL = écrire SA PROPRE requête comme source. Contrôle et PERFORMANCE maximum : jointures, filtres, agrégations et sous-requêtes côté BASE.
- Usages : requêtes COMPLEXES (sous-requêtes, UNION, agrégations, fonctions), contrôle total, performance. PARAMÈTRES intégrés (filtrage côté serveur).
- MULTI-SOURCES : jointures ou SQL (même base) ; SOUS-RAPPORTS pour sources DIFFÉRENTES ; multi-connexions possible mais jointures CÔTÉ CLIENT (coûteuses) ; consolider en amont pour les cas lourds.
- Exige de MAÎTRISER le SQL (requête valide et optimisée) et c'est du CODE à MAINTENIR.
Défi 48h — appliquez demain
Convertissez un rapport lent : réécrivez sa source en commande SQL (filtre paramétré + agrégation côté base), mesurez le gain et documentez la requête.
- Je sais écrire une commande SQL valide et optimisée avec paramètres.
- Je sais choisir l'approche multi-sources selon la nature des sources.
- Je travaille en lecture seule, sans credential en dur, requête documentée.
Questions fréquentes
Quand écrire une commande SQL plutôt que d'utiliser l'interface de sélection des tables ?
L'INTERFACE (tables + liens, Crystal génère la requête) est accessible, visuelle et facile à maintenir : le choix par défaut pour la majorité des rapports. Écrivez une COMMANDE SQL pour : les requêtes COMPLEXES que l'interface gère mal (sous-requêtes, UNION, agrégations avancées, fonctions spécifiques), la PERFORMANCE maximale (pousser jointures, filtres et agrégations à la base — décisif sur gros volumes), le CONTRÔLE précis sur la requête. Condition : maîtriser le SQL (requête valide, optimisée, documentée). En cas de doute, commencez par l'interface et passez au SQL en butant sur une limite.
Comment combiner des données de plusieurs sources différentes ?
Selon la nature des sources. MÊME base → JOINTURES ou commande SQL : la base combine en une requête (performant). Sources DIFFÉRENTES non jointables → SOUS-RAPPORTS liés (chaque source dans son rapport, lié par un champ commun ; performance au niveau du groupe) ou multi-connexions (Crystal combine CÔTÉ CLIENT — lent sur gros volumes, petits cas uniquement). Pour des combinaisons complexes, récurrentes ou volumineuses, le plus robuste est de CONSOLIDER en amont (vue, table de synthèse, ETL) puis de brancher un rapport sur source unique.
Que permet une commande SQL par rapport à la sélection de tables ?