Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
918 connectés 

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [ACCESS] [RESOLU] Problème de doublon récalcitrant

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[ACCESS] [RESOLU] Problème de doublon récalcitrant

n°2018498
alkashee
Si c'est pas beau ca !
Posté le 23-08-2010 à 15:52:30  profilanswer
 

Bonjour,
 
Voila j'ai un petit problème au taff concernant des données issues d'une base Access. Petit schéma pour mieux expliquer mon problème:
 
 

Code :
  1. NOM_SITE | NUM_PORT | ADRESSE_IP | SOUS_RESEAU | NOM_LAN | FONCTION
  2. -------------------------------------------------------------------
  3. Paris    | Fa0/1    |10.12.232.1 | 10.12.232.0 | Prod 1  | @ LAN
  4. Paris    | Fa0/1    |10.12.232.10| 10.12.232.0 | Prod 1  | @ HSRP


 
Le problème est le suivant: dans la majorité des cas, la ligne fait doublon, seule celle avec '@ LAN' suffirait. Un simple filtrage de la requête sur "@ LAN" serait la solution du problème. Seulement dans une minorité de cas, il n'y a qu'une seule ligne de donnée avec "@ HSRP' dans la colonne "fonction".
 
Ma question est donc la suivante: Comment arriver à programmer la requête pour qu'en cas de doublon elle garde que celle avec "@ LAN" ?
 
Merci pour vos réponses  :jap:


Message édité par alkashee le 30-08-2010 à 10:38:03
mood
Publicité
Posté le 23-08-2010 à 15:52:30  profilanswer
 

n°2018506
rengzehn
Posté le 23-08-2010 à 16:58:47  profilanswer
 

dans ton exemple c'est un doublon ? parceque l'ip est différente.
 
sinon un truc du genre :
 
SELECT Table1.NOM_SITE, Table1.NUM_PORT, Table1.ADRESSE_IP, Table1.SOUS_RESEAU, Table1.NOM_LAN, Last(Table1.FONCTION) AS DernierDeFONCTION
FROM Table1
GROUP BY Table1.NOM_SITE, Table1.NUM_PORT, Table1.ADRESSE_IP, Table1.SOUS_RESEAU, Table1.NOM_LAN;
 
tu regoupes tes chanmps sauf Fonction ou tu choisis de prendre la dernière occurence quand il y a des différences.

n°2018572
alkashee
Si c'est pas beau ca !
Posté le 24-08-2010 à 08:28:23  profilanswer
 

Bonjour,

 

Merci pour ta réponse. Oui dans mon exemple c'est un "doublon", terme peut être pas forcément le plus adapté car il y a deux champs différents mais tu comprends :pt1cable:

 

En fait, cheveu sur la soupe, ce n'est pas forcément dans cet ordre-là, des fois c'est l'inverse[:bicoun]
Le point qui me sert de repère c'est le champ Fonction qui contient "@ HSRP" en cas de ligne présente deux fois. J'ai essayé d'autres tri, genre sur l'adresse IP, mais le seul champ vraiment discriminant est "Fonction".

 

En résumé: Si deux lignes avec la même interface et le même nom LAN, garder celle avec '@ LAN'

 

Voili voilou :jap:


Message édité par alkashee le 24-08-2010 à 10:20:48

---------------
Shooter ou être shooté, that iz the question
n°2019066
alkashee
Si c'est pas beau ca !
Posté le 26-08-2010 à 10:23:36  profilanswer
 

Up :)


---------------
Shooter ou être shooté, that iz the question
n°2019083
rengzehn
Posté le 26-08-2010 à 11:03:36  profilanswer
 

Dis nous quels champs font que les lignes ne sont pas des doublons, tu dis que Fonction n'est pas discriminant mais par exemple ADRESSE_IP l'est-il ?

n°2019144
alkashee
Si c'est pas beau ca !
Posté le 26-08-2010 à 14:47:17  profilanswer
 

Non justement 'fonction' EST discriminant ! C'est le seul champ qui me permette de savoir quelle est la ligne à garder, 'Adresse_IP' est changeant mais pas discriminant :)


---------------
Shooter ou être shooté, that iz the question
n°2019178
rengzehn
Posté le 26-08-2010 à 15:30:06  profilanswer
 

Alors il faut aussi enlever adresse_ip du grouped_by

n°2019400
alkashee
Si c'est pas beau ca !
Posté le 27-08-2010 à 15:30:48  profilanswer
 

J'ai oublié de préciser: ce n'est pas tout le temps comme ca:

 
Code :
  1. @ LAN
  2. @ HSRP
 

Ca peut aussi être l'inverse (pourquoi faire simple quand on peut faire compliqué)...


Message édité par alkashee le 27-08-2010 à 15:30:56

---------------
Shooter ou être shooté, that iz the question
n°2019808
alkashee
Si c'est pas beau ca !
Posté le 30-08-2010 à 10:36:47  profilanswer
 

Bon j'ai résolu mon problème finalement, foutu SQL :o  
 

Code :
  1. SELECT [TEST-TABLE].Nom_Equipement, [TEST-TABLE].Nom_Site, [TEST-TABLE].Num_Port, IIf(First([Fonction])="@ IP LAN",First([Adresse_IP]),Last([Adresse_IP])) AS A_Adresse_IP, [TEST-TABLE].Sous_Reseau, [TEST-TABLE].Masque, [TEST-TABLE].Nom_LAN, IIf(First([Fonction])="@ IP LAN",First([Fonction]),Last([Fonction])) AS A_Fonction
  2. FROM [TEST-TABLE]
  3. GROUP BY [TEST-TABLE].Nom_Equipement, [TEST-TABLE].Nom_Site, [TEST-TABLE].Num_Port, [TEST-TABLE].Sous_Reseau, [TEST-TABLE].Masque, [TEST-TABLE].Nom_LAN
  4. ORDER BY [TEST-TABLE].Nom_Equipement, [TEST-TABLE].Num_Port;


 
Sur les deux champs 'Adresse_IP' et 'Fonction' je fais le test suivant (avec les champs qui vont bien à chaque fois bien entendu):
 

Code :
  1. A_Fonction: VraiFaux(Premier([Fonction])="@ IP LAN";Premier([Fonction]);Dernier([Fonction]))


(Note: le nom 'A_Fonction' est utilisé pour distinguer du champ originel 'Fonction')
 
Voila si ca peut aider certain  :hello:  
 
 


---------------
Shooter ou être shooté, that iz the question

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [ACCESS] [RESOLU] Problème de doublon récalcitrant

 

Sujets relatifs
Problème de connexionprobleme de calcul matriciel
Problème requête PDO[Resolu] Probléme de compatibilité entre Firefox et Internet Explorer
problème de calucul de temps.probleme critere sur date
Access, impossible d'atteindre nouvel enregistrementprobleme d'execution netbeans java
Probleme de compilation visual c++ 2008 
Plus de sujets relatifs à : [ACCESS] [RESOLU] Problème de doublon récalcitrant


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR