intégrité référentielle + clé double

Le
MAGALIE
Slt,

J'ai une table "FACTURES" avec une cl double
Numfour et Numfact

Dans une autre table, j'ai le suivi des factures avec
Numfourn, Numfact, Numsignataire (cl triple)

Je souhaiterai lorsque je supprime une facture que tous
les suivis correspondants se suppriment.

L'intgrit referentielle aurait fait mon affaire mais il
refuse Pourquoi ? quelle solution me proposez vous ?

>Nb : je tiens mes cls pour viter les doublons !


Merci davance


Le message est le suivant :
"Index unique introuvable pour le champ referenc d'une
table principale."

J'ai vid les 2 tables et toujours le meme pb.
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
codial
Le #5033511
En fait il faut que dans l'autre table Numfourn, Numfact ne soient pas une
clé ainsi tu peux faire une relation 1 à N avec l'intégriété référentielle.
Codial



"MAGALIE" news:184e301c422c1$605a9c40$
Slt,

J'ai une table "FACTURES" avec une clé double
Numfour et Numfact

Dans une autre table, j'ai le suivi des factures avec
Numfourn, Numfact, Numsignataire (clé triple)

Je souhaiterai lorsque je supprime une facture que tous
les suivis correspondants se suppriment.

L'intégrité referentielle aurait fait mon affaire mais il
refuse ... Pourquoi ? quelle solution me proposez vous ?

Nb : je tiens à mes clés pour éviter les doublons !



Merci davance


Le message est le suivant :
"Index unique introuvable pour le champ referencé d'une
table principale."

J'ai vidé les 2 tables et toujours le meme pb.

[MVP] Maxence HUBICHE
Le #5033471
Il ne faut pas confondre Clé et unicité !

Tu dois avoir UN champ qui serve de clé primaire.
Les Clé Priamires Multichamp devraient être bannies. Si elles existent, il
ne s'agit que d'une facilité pour mettre en place un index unique
multichamp.

Dans ta table Factures, tu dois avoir UN SEUL identifiant, UN SEUL champ.
Ensuite, tu peux, si tu veux, demander que l'association de 2 autres champs
soit unique en créant un index multichamp.
Pour ce faire,
- tu cliques (en mode dréation / la table) sur le bouton avec un éclair
jaune, juste à c$oté de la petite clé.
- tu saisis un nom dans la colonne de gauche.
- tu enquille les uns sous les autres les noms des colonnes à mettre dans
l'index unique (en préférant en première colonne la colonne sur laquelle tu
feras le plus souvent des recherches)
- Tu re-clic sur le nom, et tu définis les propriétés dans la partie
inférieure de l'écran : Unique=Oui

Et voilà !

--
Bonne continuation :)
======================================== Maxence HUBICHE
Formateur & développeur indépendant

MVP Access

Rédacteur Access sur http://www.developpez.com
http://access.developpez.com/access/faq <<= Ici, la FAQ Access de
developpez.com
"MAGALIE" 184e301c422c1$605a9c40$
Slt,

J'ai une table "FACTURES" avec une clé double
Numfour et Numfact

Dans une autre table, j'ai le suivi des factures avec
Numfourn, Numfact, Numsignataire (clé triple)

Je souhaiterai lorsque je supprime une facture que tous
les suivis correspondants se suppriment.

L'intégrité referentielle aurait fait mon affaire mais il
refuse ... Pourquoi ? quelle solution me proposez vous ?

Nb : je tiens à mes clés pour éviter les doublons !



Merci davance


Le message est le suivant :
"Index unique introuvable pour le champ referencé d'une
table principale."

J'ai vidé les 2 tables et toujours le meme pb.



---
Ce message est certifié sans virus
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.656 / Virus Database: 421 - Release Date: 09/04/2004

Eric
Le #5033291
Bonjour Maxence,

Je suis un peu hésitant avec ce principe notamment dans le cas de
relations plusieurs à plusieurs (ex: Facture-ligneFacture-Article). On
est d'accord, toute table doit avoir une clé primaire.
La table LigneFacture est une association porteuse d'informations, cette
table doit avoir une clé primaire qui, à l'évidence me parait-il, est la
concaténation du NumFacture et de la RefArticle, ce qui interdit que sur
une même facture, il ne puisse y avoir de doublons, par ex : NumFacture 200 et en détail: RefArticle="X00099" et qtéP 2 fois.
Certains préconisent alors de créer un champ du genre NumLigne dans la
table LigneFacture pour clé primaire mais alors on ne respecte plus la
normalisation puisqu'on pourrait avoir pour une meme facture 2 lignes
identiques, la clé NumLigne permettant de contourner le prob de
l'unicité.

Eternel débat,
A suivre

Eric

"[MVP] Maxence HUBICHE" news:#:

Il ne faut pas confondre Clé et unicité !

Tu dois avoir UN champ qui serve de clé primaire.
Les Clé Priamires Multichamp devraient être bannies. Si elles
existent, il ne s'agit que d'une facilité pour mettre en place un
index unique multichamp.

Dans ta table Factures, tu dois avoir UN SEUL identifiant, UN SEUL
champ. Ensuite, tu peux, si tu veux, demander que l'association de 2
autres champs soit unique en créant un index multichamp.
Pour ce faire,
- tu cliques (en mode dréation / la table) sur le bouton avec un
éclair jaune, juste à c$oté de la petite clé.
- tu saisis un nom dans la colonne de gauche.
- tu enquille les uns sous les autres les noms des colonnes à mettre
dans l'index unique (en préférant en première colonne la colonne sur
laquelle tu feras le plus souvent des recherches)
- Tu re-clic sur le nom, et tu définis les propriétés dans la partie
inférieure de l'écran : Unique=Oui

Et voilà !



Pierre CFI [mvp]
Le #5033281
bonjour
c'est à definir dans l'expression des besoins, dans la base comptoir, effectivement on ne peux pas avoir 2 lignes de détail avec le
méme produit
mais si je gére une épicerie, dur dur, il faut que je regroupe d'abord les articles identiques, fasse la somme... et si mon client
fait des courses pour plusieurs personnes qui veulent avoir le décompte séparé... là il faut une clé détail

--
Pierre CFI
MVP Microsoft Access
Mail : http://cerbermail.com/?z0SN8cN53B

Site pour bien commencer
http://users.skynet.be/mpfa/
Site perso
http://access.cfi.free.fr
"Eric"
Bonjour Maxence,

Je suis un peu hésitant avec ce principe notamment dans le cas de
relations plusieurs à plusieurs (ex: Facture-ligneFacture-Article). On
est d'accord, toute table doit avoir une clé primaire.
La table LigneFacture est une association porteuse d'informations, cette
table doit avoir une clé primaire qui, à l'évidence me parait-il, est la
concaténation du NumFacture et de la RefArticle, ce qui interdit que sur
une même facture, il ne puisse y avoir de doublons, par ex : NumFacture > 200 et en détail: RefArticle="X00099" et qtéP 2 fois.
Certains préconisent alors de créer un champ du genre NumLigne dans la
table LigneFacture pour clé primaire mais alors on ne respecte plus la
normalisation puisqu'on pourrait avoir pour une meme facture 2 lignes
identiques, la clé NumLigne permettant de contourner le prob de
l'unicité.

Eternel débat,
A suivre

Eric

"[MVP] Maxence HUBICHE" news:#:

Il ne faut pas confondre Clé et unicité !

Tu dois avoir UN champ qui serve de clé primaire.
Les Clé Priamires Multichamp devraient être bannies. Si elles
existent, il ne s'agit que d'une facilité pour mettre en place un
index unique multichamp.

Dans ta table Factures, tu dois avoir UN SEUL identifiant, UN SEUL
champ. Ensuite, tu peux, si tu veux, demander que l'association de 2
autres champs soit unique en créant un index multichamp.
Pour ce faire,
- tu cliques (en mode dréation / la table) sur le bouton avec un
éclair jaune, juste à c$oté de la petite clé.
- tu saisis un nom dans la colonne de gauche.
- tu enquille les uns sous les autres les noms des colonnes à mettre
dans l'index unique (en préférant en première colonne la colonne sur
laquelle tu feras le plus souvent des recherches)
- Tu re-clic sur le nom, et tu définis les propriétés dans la partie
inférieure de l'écran : Unique=Oui

Et voilà !






[MVP] Maxence HUBICHE
Le #5032701
De plus, pour ajouter aux informations de Pierre, sur le plan analytique, il
n'y a d'identifiant que dans les entités... pas dans les associations. Or,
LignesFacture est une association. Donc, pas d'identifiant.
Tu ne mettrais un identifiant que si tu considérais LigneFacture comme une
entité. C'est à dire un élément que tu voudrais gérer comme une fichie et
qui permettrait ultérieurement de gérer des associations (par exemple, tu
fais du flux tendu, et tu souhaites pouvoir livrer la ligne de commande en
plusieurs fois, en fonction de la quantité d'articles que tu as en
stock,etc. etc.)
Das ce cas, l'unicité N°Cde-Produit se gère par un Index-Unique-Multichamps.
Et ça marche super bien en plus.
Il y a l'unicité attendues sur l'association des 2 champs et une clé
primaire que tu peux réutiliser simplement :)

Bonne continuation :)
======================================== Maxence HUBICHE
Formateur & développeur indépendant

MVP Access

Rédacteur Access sur http://www.developpez.com
http://access.developpez.com/access/faq <<= Ici, la FAQ Access de
developpez.com
"Pierre CFI [mvp]" news: eXT$
bonjour
c'est à definir dans l'expression des besoins, dans la base comptoir,
effectivement on ne peux pas avoir 2 lignes de détail avec le

méme produit
mais si je gére une épicerie, dur dur, il faut que je regroupe d'abord les
articles identiques, fasse la somme... et si mon client

fait des courses pour plusieurs personnes qui veulent avoir le décompte
séparé... là il faut une clé détail


--
Pierre CFI
MVP Microsoft Access
Mail : http://cerbermail.com/?z0SN8cN53B

Site pour bien commencer
http://users.skynet.be/mpfa/
Site perso
http://access.cfi.free.fr
"Eric" news:

Bonjour Maxence,

Je suis un peu hésitant avec ce principe notamment dans le cas de
relations plusieurs à plusieurs (ex: Facture-ligneFacture-Article). On
est d'accord, toute table doit avoir une clé primaire.
La table LigneFacture est une association porteuse d'informations, cette
table doit avoir une clé primaire qui, à l'évidence me parait-il, est la
concaténation du NumFacture et de la RefArticle, ce qui interdit que sur
une même facture, il ne puisse y avoir de doublons, par ex : NumFacture > > 200 et en détail: RefArticle="X00099" et qtéP 2 fois.
Certains préconisent alors de créer un champ du genre NumLigne dans la
table LigneFacture pour clé primaire mais alors on ne respecte plus la
normalisation puisqu'on pourrait avoir pour une meme facture 2 lignes
identiques, la clé NumLigne permettant de contourner le prob de
l'unicité.

Eternel débat,
A suivre

Eric

"[MVP] Maxence HUBICHE" news:#:

Il ne faut pas confondre Clé et unicité !

Tu dois avoir UN champ qui serve de clé primaire.
Les Clé Priamires Multichamp devraient être bannies. Si elles
existent, il ne s'agit que d'une facilité pour mettre en place un
index unique multichamp.

Dans ta table Factures, tu dois avoir UN SEUL identifiant, UN SEUL
champ. Ensuite, tu peux, si tu veux, demander que l'association de 2
autres champs soit unique en créant un index multichamp.
Pour ce faire,
- tu cliques (en mode dréation / la table) sur le bouton avec un
éclair jaune, juste à c$oté de la petite clé.
- tu saisis un nom dans la colonne de gauche.
- tu enquille les uns sous les autres les noms des colonnes à mettre
dans l'index unique (en préférant en première colonne la colonne sur
laquelle tu feras le plus souvent des recherches)
- Tu re-clic sur le nom, et tu définis les propriétés dans la partie
inférieure de l'écran : Unique=Oui

Et voilà !









---
Ce message est certifié sans virus
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.656 / Virus Database: 421 - Release Date: 09/04/2004



Publicité
Poster une réponse
Anonyme