Champs ambigu => clause is ambiguous

[LostRailler]

Bonjour,

Je me traine un problème que je ne comprend pas, peut-être qu'un regard extérieur pourra m'aider

J'ai une requête SQL qui passe dans MySQL mais pas en PHP.

C'est une requête entre 2 table et l'erreur qui m'est remontée et la suivante :

Column 'id_regle' in where clause is ambiguous

Voici la structure des 2 tables concernées :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
 
CREATE TABLE SIEBEL_ST (
  si_ref varchar(50),
  si_categorie1 varchar(100),
  si_categorie2 varchar(100),
  si_motif varchar(100),
  si_compte varchar(100),
  si_nom_client varchar(100),
  si_prenom_client varchar(100),
  si_tel_principal varchar(15),
  si_tel_secondaire varchar(15),
  si_commentaire varchar(2000),
  si_conclusion_st varchar(2000),
  si_statut varchar(100),
  si_sous_traitant varchar(100),
  si_assigne_a varchar(50),
  si_position_assigne_a varchar(50),
  si_ref_gti varchar(50),
  si_retour_sous_traitance date,
  si_sous_traitance date,
  si_cree_le date,
  si_modifie_le date,
  si_type_equipement varchar(100),
  si_date_envoi_equipement date,
  si_statut_envoi_equipement varchar(50),
  si_date_retrait_equipement date,
  si_etat_livraison_equipement varchar(50),
  si_code_postal int(10),
  si_date_dernier_AE_AS date,
  si_activite_AE_AS varchar(100),
  si_type varchar(100),
  si_date_planifie date,
  si_priorite varchar(100),
  id_regle bigint(20),
  PRIMARY KEY (si_ref),
  INDEX (si_ref),
  FOREIGN KEY (si_ref) REFERENCES CAS_CLIENT(si_ref_cas),
  FOREIGN KEY (si_ref_gti) REFERENCES CLARIFY_TICKET(cl_idcas),
  FOREIGN KEY (id_regle) REFERENCES REGLE(id_regle),
  FOREIGN KEY (si_assigne_a) REFERENCES UTILISATEUR(log_si_utilisateur)
);
 
CREATE TABLE CAS_CLIENT (
  si_ref_cas varchar(50),
  flag_cas int(3),
  traite_par_cas varchar(50),
  prioritaire_cas BOOLEAN,
  mouli_synchro int(4) DEFAULT '0',
  mouli_stabilite int(4) DEFAULT '0',
  mouli_voip int(4) DEFAULT '0',
  mouli_tv int(4) DEFAULT '0',
  retour_synchro timestamp NULL,
  retour_stabilite timestamp NULL,
  retour_voip timestamp NULL,
  retour_tv timestamp NULL,
  heure_traitement timestamp NULL,
  PRIMARY KEY (si_ref_cas),
  INDEX (si_ref_cas),
  FOREIGN KEY (si_ref_cas) REFERENCES SIEBEL_ST(si_ref)
);

Et voici la fameuse requête qui me pose soucis :

Code :

1
2
3
4
5
6
7
 
SELECT COUNT(*) 
FROM CAS_CLIENT 
INNER JOIN SIEBEL_ST ON CAS_CLIENT.si_ref_cas = SIEBEL_ST.si_ref 
WHERE SIEBEL_ST.id_regle IS NULL 
AND flag_cas IS NULL 
AND si_assigne_a = 'TOTO'

Si vous pouvez m'aider ?
Merci d'avance car là je sèche

[CinePhil]

Column 'id_regle' in where clause is ambiguous

Dans la mesure où tu as préfixé cette colonne du nom de la table d'où elle est extraite et comme en plus cette colonne ne figure pas dans l'autre table impliquée dans la requête, je ne vois pas pourquoi il considère cette colonne comme ambiguë !

Ce qui n'est pas bien par contre, c'est que cette colonne est une clé étrangère pouvant semble t-il être à NULL.

[ninikkhuet]

Bonjour,

je ne sais déjà pas comment tu as pu créer tes tables, chez moi j'ai une erreur 150 "Can't create table" :
dans ta table SIEBEL_ST, tu as la clé étrangère si_ref vers le champ si_ref_cas de ta table CAS_CLIENT, qui a elle-même la clé étrangère si_ref_cas vers le champ si_ref de ta table SIEBEL_ST...Erreur de copier-coller ?

[LostRailler]

Bonjour,

J'ai demandé à ce que le sujet soit fermé mais j'ai du faire une mauvaise manip.

Le schéma SQL ici est incomplet, il prend en compte uniquement les 2 tables concernées, d'où l'erreur de création.

La clé étrangère ici peut être nulle car c'est une relation 0,n.

Sinon en ce qui concerne le problème, c'est une erreur complètement idiote de ma part. Je suis en PHP et dans mon message d'erreur je ne faisais pas afficher la bonne requête
Et en fait il manquait bien le nom de ma table devant le champs id_regle.

Désolé de cette gêne

[CinePhil]

Envoyé par LostRailler

La clé étrangère ici peut être nulle car c'est une relation 0,n.

Euh...
Qu'appelles-tu 0,n ?

Les différents cas possibles pour une association :

1) A -x,n----Associer----x,n- B avec x = 0 ou 1
Cardinalités maximales à n => Table associative.

2) A -0,x----Associer----0,x- B avec x = 1 ou n
Cardinalités minimales à n => Table associative.

3) A -0,1----Associer----1,n- B
1 cardinalité minimale à 0 et l'autre cardinalité maximale à n => Table associative.

4) A -1,1----Associer----1,1- B
Toutes les cardinalités à 1 => En principe fusion des deux entités ou choix d'une des deux tables issues des entités pour porter la clé étrangère.

5) A -1,1----Associer----x,y- B avec x <> y
Cardinalités 1,1 sur une seule entité => Clé étrangère dans la table issue de l'entité située du côté 1,1.

6) A -x,y----Associer----z,u- B
C -t,v--------------|
Plus de deux entités associées => Table associative.

Conclusion : les seuls cas où il n'y a pas de table associative sont ceux où on trouve des cardinalités 1,1.

[LostRailler]

Arf je ne sais plus écrire.

Voici la relation que j'ai entre ma table SIEBEL_ST et REGLE :
SIEBEL_ST 0,1----Associer----0,n REGLE

Un cas Siebel est associé à aucune ou une seule règle
A une règle peut correspondre aucun ou plusieurs cas Siebel

[CinePhil]

Envoyé par LostRailler

Voici la relation que j'ai entre ma table SIEBEL_ST et REGLE :
SIEBEL_ST 0,1----Associer----0,n REGLE

Tu devrais donc avoir une table associative pour éviter de peupler la table SIEBEL_ST de bonshommes NULL.

[LostRailler]

Les tables associatives c'est quand tu as une relation x,n - x,n
Je n'en vois pas l'intérêt dans ce cas la. Se serait passer par une table supplémentaire lors des requêtes.

[CinePhil]

Parce que bonhomme NULL est à bannir autant que possible, et surtout pour les clés étrangères. Il perturbe le SGBD et nuit aux performances.
C'est expliqué par fsmrel plusieurs fois dans le forum Schema ou le forum Merise mais je ne retrouve pas de messages dans l'instant.

Sinon, bis repetita de ma part sur le principe :

Les différents cas possibles pour une association :

1) A -x,n----Associer----x,n- B avec x = 0 ou 1
Cardinalités maximales à n => Table associative.

2) A -0,x----Associer----0,x- B avec x = 1 ou n
Cardinalités minimales à n => Table associative.

3) A -0,1----Associer----1,n- B
1 cardinalité minimale à 0 et l'autre cardinalité maximale à n => Table associative.

4) A -1,1----Associer----1,1- B
Toutes les cardinalités à 1 => En principe fusion des deux entités ou choix d'une des deux tables issues des entités pour porter la clé étrangère.

5) A -1,1----Associer----x,y- B avec x <> y
Cardinalités 1,1 sur une seule entité => Clé étrangère dans la table issue de l'entité située du côté 1,1.

6) A -x,y----Associer----z,u- B
C -t,v--------------|
Plus de deux entités associées => Table associative.

Conclusion : les seuls cas où il n'y a pas de table associative sont ceux où on trouve des cardinalités 1,1.

[LostRailler]

Donc pour résumé tu conseilles que je crée une table avec uniquement pour valeur si_ref et id_regle ?

[CinePhil]

Oui, avec si_ref en clé primaire et id_regle en clé étrangère.

Et au passage, si si_ref est une référence alphanumérique de plus de 3 caractères, c'est une mauvaise clé !