Nb : je tiens à mes clés pour éviter les doublons !
Nb : je tiens à mes clés pour éviter les doublons !
Nb : je tiens à mes clés pour éviter les doublons !
Nb : je tiens à mes clés pour éviter les doublons !
Nb : je tiens à mes clés pour éviter les doublons !
Nb : je tiens à mes clés pour éviter les doublons !
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à !
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à !
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à !
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" écrivait
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à !
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" <mh.webmaster@club-internet.fr> écrivait
news:#hFP2RsIEHA.3060@TK2MSFTNGP11.phx.gbl:
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à !
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" écrivait
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à !
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" a écrit dans le message de
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" écrivait
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à !
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" <f_framZZ@hotmail.com> a écrit dans le message de
news:XnF94CC761E8674FfframZZhotmailcom@207.46.248.16...
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" <mh.webmaster@club-internet.fr> écrivait
news:#hFP2RsIEHA.3060@TK2MSFTNGP11.phx.gbl:
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à !
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" a écrit dans le message de
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" écrivait
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à !
