Meilleur auteur de réponses
Problème avec LOOKUP dans SSIS qui retourne des doublons

Question
-
Bonjour à tous, j'ai un petit problème avec le composant LOOKUP de SSIS, j'ai une table destination que j'alimente à partir d'une table source (les deux tables sont sur le même serveur SQL SERVER) tout en vérifiant qu'il n'y a pas d'enregistrement déjà existant, le problème c'est qu'à la sortie du lookup (Sortie de recherche sans correspondance) lorsque ma table destination est vide il la remplit avec des enregistrements en doublons et dés que je relance le package il retourne (Sortie de recherche avec correspondance) les lignes en doublons,je sais pas si l'insertion se fait en bloc est que SSIS ne vérifie pas après chaque insertion s'il y a des doublons ou non? la table source à la même structure que la table destination:
N° TRAIN | DATE |TYPE |CAPACITE
TR001 | 01/01/2011|EXPRESS | 1000
TR001 | 01/01/2011|EXPRESS | 1000
TR002 | 15/01/2011|EXPRESS | 1500
Normalement en fin du traitement je trouve que deux enregistrement pas 3 or c'est pas le cas, voici une capture du package (partie droite TRAIN)
Je sais pas si c'est bon au niveau des colonnes ou non- Modifié bouazizimedridha mardi 6 septembre 2011 11:24
- Déplacé Christian Robert - MCT - MCM mardi 6 septembre 2011 17:18 SSIS donc BI (Origine :SQL Server pour les développeurs)
mardi 6 septembre 2011 11:17
Réponses
-
Bonjour
Désolé de reprendre la suite un peu plus tard, j'ai été un peu occupé ces derniers jours.
Les flèches c'est les colonnes sur lesquelles se fait le lookup, vous indiquez dans le premier cas que vous cherchez les lignes de votre table d'origine (appellons là ORG) qui ont une égalité sur les colonnes TYPE et CAPACITE avec la table destination (appelons là DEST). Chaque ligne de la table ORG est comparée avec l'ensemble des lignes des la table DEST, dès qu'une égalité entre TYPE/CAPACITE est trouvé avec n'importe quelle ligne de DEST, cette ligne est renvoyé sur le flux de sortie "match" de la tache de lookup.
Les coches ne sont là que pour ajouter des colonnes de la table DEST, sur le matching. Reprenons le premier des 4 exemples, dès qu'une correspondance sera trouvée sur type et capacité, on ajoutera les valeurs des colonnes NO_TRAIN et DATE de la table DEST à celle de la table ORG.
Dans votre cas çà ne sert d'inclure une quelconque colonne de la table ORG, comme vous le dites vous même soit le couple NO_TRAIN/DATE n'existe pas et vous voulez l'insérer (depuis la table ORG), soit il existe et vous voulez écraser les valeurs de TYPE et CAPACITE de DEST avec les valeurs trouvées dans ORG.
Vous devriez donc avoir 2 flèches entre NO_TRAIN et DATE, et rien de coché dans la partie droite.
Il vous faudra utiliser les 2 sorties du LOOKUP, la première (match) qui ira directement insérer dans la table de destination et la seconde (non match) qui pointera sur une tâche SQL qui ira effectuer un UPDATE sur la table DEST.J'espère avoir été plus clair, le lookup n'étant pas la tâche la plus simple à expliquer :o(
Bonne journée
Christian Robert - MVP SQL Server - Microsoft Certified Master - SQL Server 2008
Blog : http://www.sqlnco.ch
Groupe des Utilisateurs Francophone de SQL Server : http://www.guss.fr- Proposé comme réponse Christian Robert - MCT - MCM mardi 13 septembre 2011 14:21
- Marqué comme réponse Roxana PANAITMicrosoft employee vendredi 16 septembre 2011 10:46
vendredi 9 septembre 2011 16:13
Toutes les réponses
-
Bonjour à tous, j'ai un petit problème avec le composant LOOKUP de SSIS, j'ai une table destination que j'alimente à partir d'une table source (les deux tables sont sur le même serveur SQL SERVER) tout en vérifiant qu'il n'y a pas d'enregistrement déjà existant, le problème c'est qu'à la sortie du lookup (Sortie de recherche sans correspondance) lorsque ma table destination est vide il la remplit avec des enregistrements en doublons et dés que je relance le package il retourne (Sortie de recherche avec correspondance) les lignes en doublons,je sais pas si l'insertion se fait en bloc est que SSIS ne vérifie pas après chaque insertion s'il y a des doublons ou non? la table source à la même structure que la table destination:
N° TRAIN | DATE |TYPE |CAPACITE
TR001 | 01/01/2011|EXPRESS | 1000
TR001 | 01/01/2011|EXPRESS | 1000
TR002 | 15/01/2011|EXPRESS | 1500
Normalement en fin du traitement je trouve que deux enregistrement pas 3 or c'est pas le cas, voici une capture du package (partie droite TRAIN)
Je sais pas si c'est bon au niveau des colonnes ou nonj'ai cherché partout est j'ai modifié et essayé tout type solution que je connais sans résultat.
Merci pour vos aides.
- Modifié bouazizimedridha mardi 6 septembre 2011 11:22
- Fusionné Christian Robert - MCT - MCM mardi 6 septembre 2011 17:16 Même question
mardi 6 septembre 2011 11:14 -
Bonjour
Pour être bien sûr de cerner votre problème, vous avez des doublons dès la première execution, alors que la table est préalablement vide.
Ou alors à la seconde execution ? C'est là où je ne vous suis pas trop ?
De plus vous faites le lookup sur la même table que la sorce ?
Merci d'avances de ces précisions.
Bonne journée
Christian Robert - MVP SQL Server - Microsoft Certified Master - SQL Server 2008
Blog : http://www.sqlnco.ch
Groupe des Utilisateurs Francophone de SQL Server : http://www.guss.frmardi 6 septembre 2011 16:28 -
Bonjour,
Tout d'abord j'ai posté sur les deux forums pour avoir plus de réponse sinon comment faire et quel forum dois-je choisir pour postuler?
Pour le problème de lookup j'ai des doublons dés la première exécution et la table source est destination sont différente juste ils sont dans le même serveur, et je pense déjà avoir la solution j'ai dû ajouté le composant de trie afin d'éviter les doublons et ça marche apparemment, mais il me reste ambigu le truc de colonnes et leurs mappage, quelle est la signification de la liaison ainsi que la case à cocher et c'est quoi la différence entre les deux?
Merci
mardi 6 septembre 2011 19:57 -
Bonjour
Pas de soucis pour le double post, je l'ai fusionné et remis dans le bon forum.
A votre décharge le forum BI n'est visible que sur le TechNet. Si vous avez des question sur SSIS je vous conseile de les poster ici (SQL Server - Décisionnel (modules BI de SQL Server) ), c'est le bon endroit.
La liaison ou les liaisons c'est le lookup que vous réalisez entre les 2 tables, dans votre cas vous recherchez les enregistrements ayant les même valeurs pour la colonne DATE et la colonne CAPACITE. Si vous cochez une colonne dans la partie droite celà signifie que vous souhaitez ajouter cette colonnes à la sortie du la tache de lookup et potentiellement à la table de destination.
Effectivement le composant de tri peut vous aider à dédoublonner le jeu de données.
Je crois que je comprends votre problème maintenant. Il faut lier les 2 tables sur toutes les colonnes ou sur une clef unique s'il y en a une dans la table.
Dans votre cas la comparaison se fait uniquement sur DATE et CAPACITE d'où le risque de doublon. Pas la peine de cocher de colonnes, c'est la même table, vous avez déjà les colonnes utiles.Bonne soirée.
Christian Robert - MVP SQL Server - Microsoft Certified Master - SQL Server 2008
Blog : http://www.sqlnco.ch
Groupe des Utilisateurs Francophone de SQL Server : http://www.guss.frmardi 6 septembre 2011 21:39 -
Bonjour,
Pour mieux vous clarifier la situation, j'ai une table (temporaire et sans clé primaire) source qui contient des enregistrement de trains, exemple
N° TRAIN | DATE |TYPE |CAPACITE
TR001 | 01/01/2011|EXPRESS | 1000
TR001 | 01/01/2011|EXPRESS | 1000
TR002 | 15/01/2011|EXPRESS | 1500
je veux remplir une table destination avec de même structure que la source (N° TRAIN, DATE, TYPE, CAPACITE) mais avec comme clé primaire (N° TRAIN,DATE), je veux la remplir sans doublons, en prenant l'exemple ci-dessus la table destination doit contenir deux enregistrement seulement et à chaque nouveau insertion on veille qu'on a pas dans la destination le même enregistrement que celui qu'on insert, si l'enregistrement existe il faut mettre à jour les champs TYPE et CAPACITE
pour le moment tout cela passe bien apparemment mais comme je l'ai dit j'arrive pas à comprendre la différence entre les liaisons (flèches) et les cases à cocher au niveau des colonnes, par exemple pour les liaisons ci dessous je sais pas laquelle est la bonne et qu'est ce que cela signifie :(
Merci de nouveau,
- Modifié bouazizimedridha mercredi 7 septembre 2011 08:17
mercredi 7 septembre 2011 08:03 -
Bonjour
Désolé de reprendre la suite un peu plus tard, j'ai été un peu occupé ces derniers jours.
Les flèches c'est les colonnes sur lesquelles se fait le lookup, vous indiquez dans le premier cas que vous cherchez les lignes de votre table d'origine (appellons là ORG) qui ont une égalité sur les colonnes TYPE et CAPACITE avec la table destination (appelons là DEST). Chaque ligne de la table ORG est comparée avec l'ensemble des lignes des la table DEST, dès qu'une égalité entre TYPE/CAPACITE est trouvé avec n'importe quelle ligne de DEST, cette ligne est renvoyé sur le flux de sortie "match" de la tache de lookup.
Les coches ne sont là que pour ajouter des colonnes de la table DEST, sur le matching. Reprenons le premier des 4 exemples, dès qu'une correspondance sera trouvée sur type et capacité, on ajoutera les valeurs des colonnes NO_TRAIN et DATE de la table DEST à celle de la table ORG.
Dans votre cas çà ne sert d'inclure une quelconque colonne de la table ORG, comme vous le dites vous même soit le couple NO_TRAIN/DATE n'existe pas et vous voulez l'insérer (depuis la table ORG), soit il existe et vous voulez écraser les valeurs de TYPE et CAPACITE de DEST avec les valeurs trouvées dans ORG.
Vous devriez donc avoir 2 flèches entre NO_TRAIN et DATE, et rien de coché dans la partie droite.
Il vous faudra utiliser les 2 sorties du LOOKUP, la première (match) qui ira directement insérer dans la table de destination et la seconde (non match) qui pointera sur une tâche SQL qui ira effectuer un UPDATE sur la table DEST.J'espère avoir été plus clair, le lookup n'étant pas la tâche la plus simple à expliquer :o(
Bonne journée
Christian Robert - MVP SQL Server - Microsoft Certified Master - SQL Server 2008
Blog : http://www.sqlnco.ch
Groupe des Utilisateurs Francophone de SQL Server : http://www.guss.fr- Proposé comme réponse Christian Robert - MCT - MCM mardi 13 septembre 2011 14:21
- Marqué comme réponse Roxana PANAITMicrosoft employee vendredi 16 septembre 2011 10:46
vendredi 9 septembre 2011 16:13 -
Bonjour,
Merci de nous tenir au courant avec vos demarches.
Cordialement,
Roxana
Roxana PANAIT, MSFT
Votez! Appel à la contribution
Nous vous prions de considérer que dans le cadre de ce forum on n’offre pas de support technique et aucune garantie de la part de Microsoft ne peut être offerte.lundi 12 septembre 2011 16:07 -
Bonjour,
Désolé de reprendre un peu plus tard, j'ai été occupé.
Je pense avoir plus de visibilité sur le lookup même si cela reste un peu flou, à ce que j'ai compris les flèches sert à identifier les champs sur les quels se fera la recherche (généralement les clés primaires), prenons mon exemple, les champs qui sert à des clés primaires sont NO_TRAIN/DATE donc on les lient aux champs de destination par des flèches, jusqu'ici je pense que c'est bon, il reste que j'arrive pas à comprendre dans quel cas dois je cocher les cases (dans mon cas je veux insérer les enregistrement qui n'existent pas sinon je ferais un UPDATE).
Merci de nouveau
mardi 13 septembre 2011 07:34 -
Bonjour
Vous cocherez les fèches si la table sur laquelle vous faites le lookup n'est pas votre table de destination, mais une simple table de correspondance.
Par exemple, vous avez une table de toutes les communes, ainsi que leur codes postaux.
La table principale contient uniquement le code postal et vous souhaitez récupérer le nom de la communes.
Vous créez une tâche de lookup, vous tirez une flèche entre la table principale et celle des communes sur la colonne correspondant aux codes postaux.
Et vous cochez la colonne qui correspond au nom de la commune dans la table de correspondance, du coup cette colonne sera recopié dans le flux de sorti.Mais clairement çà ne s'applique pas à votre cas.
Bonne journée
Christian Robert - MVP SQL Server - Microsoft Certified Master - SQL Server 2008
Blog : http://www.sqlnco.ch
Groupe des Utilisateurs Francophone de SQL Server : http://www.guss.frmardi 13 septembre 2011 14:26 -
Bonsoir,
Ah ok donc les cases cochés sont les sorties du flux alors que les flèches sont les critère de recherche (et normalement les colonnes liés en flèches seront aussi retournées).
Je pense avoir compris le truc et c'est vrai cela ne s'applique pas à mon cas :).
Merci
mardi 13 septembre 2011 15:10