Placez-vous maintenant dans la fonction Page_Load et appelez cette fonction de cette manière :
AfficherMonumentEtVille("LEFT");
AfficherMonumentEtVille("INNER");
Nous appelons donc la même fonction mais le premier appel réalisera une requête de type LEFT alors que le deuxième appel réalisera une requête de type
Les résultats des requêtes LEFT et INNER
INNER. Voici le résultat renvoyé par ces deux requêtes : voir figure 6.
La différence entre les deux requêtes est que celle de type LEFT va renvoyer un élément de plus que celle du type INNER. En fait, la raison est assez simple et va concerner l’élément Projet.
Effectivement, celui-ci existe bien dans la liste Monuments mais son champ Ville n’a pas été défini. Il n’y a donc aucune concordance entre la valeur de ce champ et un élément dans la liste des villes. Dans ce cas, si aucune correspondance n’est trouvée entre les listes, une jointure de type INNER ne renverra carrément pas l’élément. Par contre, une jointure du type LEFT renverra quand même l’élément avec les propriétés définies dans la liste Monuments, mais étant donné qu’aucune correspondance ne sera trouvée dans la liste Villes, elle ne renverra pas les champs de cette liste. C’est en fait pour cela que nous avons testé si le champ VilleSuperficie existe bien dans le résultat avant d’effectuer des opérations dessus.
Passons maintenant à la deuxième requête. Celle-ci va effectuer une requête relativement similaire sauf qu’elle joindra également la listePays à la requête pour récupérer les informations du pays dans lequel se trouve la ville du monument. Tapez donc le squelette de la fonction comme ceci :
private void AfficherMonumentEtVilleEtPays(string type)
{
}
Nous ferons encore passer le type de la jointure en paramètre pour bien afficher la différence de type. Comme précédemment, nous commençons le code de la fonction par la récupération de la liste et la création d’un nouvel objet SPQuery :
SPList list = SPContext.Current.Web.Lists[« Monuments »];
SPQuery query = new SPQuery();
Tapez donc ensuite le code suivant pour effectuer la jointure des 3 tables : Voir Code 4 ci-dessous.
Nous effectuons ici deux jointures. La première de ces deux jointures est la même que celle que nous avons réalisée dans la fonction précédente (relisez donc l’explication de celle-ci si vous ne comprenez pas). Une fois la liste Villes jointes à la liste Monuments, nous allons devoir joindre la liste Pays à la liste Villes sur base du champ Pays de la liste Villes. Nous effectuons donc une jointure du type passé en paramètre. Nous appelons ensuite la liste Pays (déclarée implicitement par le Lookup) PaysList. Le premier FieldRef permet donc de définir une référence vers le Lookup permettant de faire la jointure. Ici, il s’agit du champ Pays dans la liste Villes. Etant donné que cette liste n’est pas celle sur laquelle la requête sera exécutée, nous devons utiliser l’attribut List de FieldRef pour indiquer l’alias de la liste contenant leLookup, donc VillesList. Le deuxième FieldRef indique simplement que la comparaison se fera avec le champ ID de la liste des pays.
Téléchargez cette ressource
Construire une infrastructure cloud optimisée pour l’IA avec Microsoft Azure
Les managers IT ont besoin d’une stratégie claire et de solutions concrètes pour préparer leur infrastructure cloud à l'adoption de l'IA, tout en optimisant les coûts, renforçant la sécurité et développant les compétences internes. Découvrez tous les conseils dans ce guide Insight.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Souveraineté numérique : les décideurs publics veulent prioriser les modèles d’IA souverains
- Dans l’œil du cyber-cyclone : l’excès d’optimisme constitue le risque principal pour la résilience des données
- Les 3 prédictions 2026 pour Java
- Infrastructures IT : 5 leviers concrets pour éviter les impasses technologiques
Articles les + lus
CES 2026 : l’IA physique et la robotique redéfinissent le futur
Les 3 prédictions 2026 pour Java
Semi-conducteurs : comment l’Irlande veut contribuer à atténuer la pénurie mondiale de puces
Face à l’urgence écologique, l’IT doit faire sa révolution
D’ici 2030, jusqu’à 90 % du code pourrait être écrit par l’IA, pour les jeunes développeurs, l’aventure ne fait que commencer
À la une de la chaîne Tech
- CES 2026 : l’IA physique et la robotique redéfinissent le futur
- Les 3 prédictions 2026 pour Java
- Semi-conducteurs : comment l’Irlande veut contribuer à atténuer la pénurie mondiale de puces
- Face à l’urgence écologique, l’IT doit faire sa révolution
- D’ici 2030, jusqu’à 90 % du code pourrait être écrit par l’IA, pour les jeunes développeurs, l’aventure ne fait que commencer
