Version imprimable
Bonjour.
J'ai créé mes relations avec 7 tables, et je stocke mes données dans une autre table qui ne fait pas partie de mes relations.
est-ce un problème pour ma routine qui est sensée stocker cetaines infos dans cette table (hors relation) tous les jours?
je vous remercie d'avance
Cordialement
Bonjour.
Il faut, dans un premier temps, bien faire la différence entre "relations" et "intégrité référentielle"... Car si les relations par défaut se placent via le même outil que l'intégrité référentielle, les deux concepts ne sont pas directement liés.
Placer une relation par défaut via le gestionnaire des relations permet à Access de proposer cette relation par défaut lors de l'utilisation de plusieurs tables, par exemple au sein d'une requête multi-tables. Cette relation peut être modifiée ponctuellement pour une requête particulière. La création des relations par défaut n'est donc qu'une "aide" pour la suite. Il n'est donc jamais grave de ne pas placer de relations entre les tables.
L'intégrité référentielle, c'est tout autre chose. C'est un mécanisme qui garantit qu'une donnée d'une table utilisée dans une autre table existe au moment d'y faire référence et existera tant que l'on y fera référence. Elle garantit donc la cohérence des données et des références, lorsque certaines données d'une table sont alimentées par une autre table. Il faut noter qu'Access ne permet pas de placer l'intégrité référentielle sans placer une relation par défaut.
Il est donc primordial de placer l'intégrité référentielle en étudiant le schéma relationnel de tes données, d'autant plus que l'intégrité s'impose à tout client des données, interne à la base comme externe. Les relations par défaut, quant à elles, ne jouent qu'à l'intérieur de la base (et des bases liées).
En résumé, si ta table, actuellement sans relations, contient des données issues d'une autre table, tu dois placer l'intégrité référentielle.
Bonsoir Pierre,
Si je ne me trompe, Kkaba n'a plus donné suite. Cependant, tes précisions claires m'ont bien servi et j'en suis sûr à d'autres aussi.
Ai-je bien raison lorsque je dis:
Dans la fenêtre des relations, il n'est pas possible d'établir l'intégrité référentielle entre un champ numérauto et un champ numérique.
Pour cette raison, et pour d'autres, je n'utilise plus jamais un champ numérauto comme clé primaire.
Merci pour tes réponses.
Marcel
Hello Marcello,
Ben si on peut:aie:Citation:
Envoyé par Marcello5255
Allons bon! Pourquoi tant de haine envers le NumeroAuto:(Citation:
Envoyé par Marcello5255
Bonsoir Fabien,
Merci pour ton attention, et voici mes réponses
Prenons l'exemple d'une facture de vente.
Elle est saisie dans un formulaire et un sous-formulaire,
Dans le formulaire, une entête facture avec les champs issus d'une requête
Date de facture
Numéro de facture = champ père
Client
et quelques autres champs et infos dont je fais grâce.
Et puis, les lignes dans le sous-formulaire avec,
Dénomination Article
Prix Article
Quantité
Total de la ligne et autres, et puis surtout
Numéro de facture = champ fils.
Je dois établir l'intégrité référentielle entre Champ père et Champs fils. Sinon, si je supprime l'entête facture, je me retrouve avec des lignes orphelines.
Numéro de facture dans les lignes est une clé secondaire, et j'ai une autre clé primaire.
Je ne peux donc logiquement attribuer le type numéroauto à cette clé secondaire. Je lui donne par exemple le type numérique.
Lorsque dans la fenêtre des relations, je veux établir l'intégrité référentielle entre NumFact de l'entête de type numéroauto, et NumFact des lignes de type numérique, je reçois le message d'erreur "incompatibilité de type"
Pourquoi je n'utilise pas un champ numéroauto comme clé primaire?
1. Pour la raison ci-dessus
2. Parce que si je dois simplement sortir et recommencer ma facture, le numéro généré, saute une position, alors que je ne peux pas avoir de trous dans la numérotation de mes factures. C'est la loi (en Belgique, mais je pense que c'est pareil en France et ailleurs), même si certain en font fi.
3. Parce que une référence 1 et puis 11 et puis 126, ce n'est pas clair.
Comment je fais:
Je détermine au début de l'année un numéro simple, par exemple 1000.
Lorsque j'introduis la date de ma facture (C'est obligatoire, une pièce comptable doit être datée et numérotée), je récupère l'année. Puisque je suis dans un formulaire facture de vente, je crée le numéro de ma facture de type texte, avec la concaténation FV Année/N°Simple.
Dans la table principale de mon sous-formulaire, j'ai un champ NumFact de type texte, qui sera champs fils, et automatiquement rempli avec la même valeur que celle du champ NumFact, aussi de type texte de mon entête facture.
Et là, je peux établir l'intégrité référentielle, la suppression en cascade, et la mise à jour en cascade.
Pour terminer, pour déterminer automatiquement le numéro de la facture suivante, j'utilise la fonction Dmax.
Je suis plus orienté comptabilité qu'informatique, et j'ai peut-être loupé ou pas bien compris toutes les subtilités de l'intégrité référentielle. Si tu peux me dire comment je peux l'établir entre un champ numéroauto et un champ numérique, dans la fenêtre des relations, ou d'autres précisions, je t'en remercie, et en tiendrai compte pour d'autres éventualités.
Bonne soirée.
Marcel
bizarre:koi:, il n'y a pas de raison à première vue.Citation:
Envoyé par Marcello5255
Pour le point 1), tu pourrais joindre un bout de base en pièce-jointe ? Doit y avoir une boulette quelque part...Citation:
Envoyé par Marcello5255
Pour les points 2) et 3):
En effet, le numéro de facture est un numéro qui obéit à des règles (pas de trous dans la numérotation, recommence à 1000 au début de l'année, etc...) et ne doit pas figurer comme clé primaire.
Facture(idFacture, NumeroFacture, DateFacture, #idClient,...) (clé primaire soulignée)
idFacture est un numéroAuto, il sert à établir la relation d'intégrité référentielle avec la table DetailFacture.
Comme il n'a aucune signification, il peut présenter des trous, et comme il sera de toute façon masqué dans les formulaires/états, l'utilisateur n'aura même pas conscience de son existence.
NumeroFacture sera donc ton numéro personnalisé, celui qui sera présenté à l'utilisateur. On peut indexer ce champ avec la propriété "Unique" à "Oui" pour éviter les doublons et lui donner ainsi la même propriété d'unicité que la clé primaire.
Tu devrais trouver d'excellents conseils dans ce tutoriel qui concerne justement la numérotation personnalisée de factures:
Numérotation personnalisée des enregistrements dans Access 2010
bonne nuit:zzz:
En tout cas, Fabien, sous Access 2007, je viens encore de faire un test simple:Citation:
bizarre, il n'y a pas de raison à première vue.
Je crée une table
"Articles"
NumArt de type numéroauto et clé primaire
Dénomination
une autre table
"Choix"
IDChoix de type numéroauto et clé primaire
NumArt de type numérique.
Dans la fenêtre relation, je fais glisser NumArt de Articles, vers NumArt de Choix
Je coche appliquer l'intégrité référentielle,
et puis click sur "créer"
Message " La relation doit inclure le même nombre de champs avec le même type de données."
Essaie peut-être si tu as une autre version.
Ceci ne me gêne pas du tout, puisque je n'utilise plus de champ numéroauto comme clé primaire. Et sur ce point tu pourras lire d'autres post de développeurs qui sont de cet avis. Je ne suis moi-même pas développeur puisque je ne crée que mes applications personnelles.
Non,non, ce n'est pas du tout ainsi que je procède: Numéro de facture est la clé primaire, l'identifiant qui sert à établir l'intégrité référentielle, je n'ai pas besoin d'un autre identifiant.Citation:
NumeroFacture sera donc ton numéro personnalisé, celui qui sera présenté à l'utilisateur. On peut indexer ce champ avec la propriété "Unique" à "Oui" pour éviter les doublons et lui donner ainsi la même propriété d'unicité que la clé primaire.
En ce qui concerne la numérotation automatique, j'irai voir le lien que tu me donnes, et je t'en remercie. Il concerne toutefois Access 2010, et je suis avec Access 2007.
Ce qui ne me gêne pas plus, puisque avec l'aide de Led Zepp, j'ai mis au point une fonction Dmax, qui réalise ceci à merveille.
Bonne et belle journée à tous.
Marcel
Bonjour Marcello5255 et Fabien,
Je confirme que nous utilisons "à tour de bras" (mais sous Access 2003), les liens et intégrité référentielle de NuméroAuto vers Numérique (Entier).
Bizarre, effectivement... il faudrait que tu joingnes un .mdb 2007 bidon, avec 2 tables de test (à l'attention de personnes équipées de Access 2007). Il serait bien, également, de faire l'inverse : que tu télécharges un .mdb 2007 bidon avec 2 tables de test (mis à disposition par une personne équipée de Access 2007).
En parallèle, je te joins un .mdb Access 2003 que tu devrais pouvoir lire.
Salut.
Il n'y a aucun problème à placer l'intégrité entre un numéroAuto et un numérique, pour autant que ce soient tous les deux des entiers longs. C'est peut-être à ce niveau que le bât blesse.
http://fauconnier.developpez.com/for...egrite2007.jpg
Voici une base qui montre cela.
Cela étant (point de vue purement personnel), je préfère travailler comme le préconise Fabien, en utilisant une clé primaire "qui ne veut rien dire" au lieu d'un numéro de facture. Je n'aime pas les clés primaires chargées de sens, dans la mesure ou si la signification change, patatra pour la suite.
Merci Pierre, Richard et Fabien,
C'est bien comme le dit Pierre parce que la clé secondaire est de type numérique, mais pas entier long, que je ne peux pas établir l'intégrité référentielle. Par défaut, mes champs numériques sont réels doubles.
J'ai refait les tests en suivant les conseils de Pierre, et ils sont probants.
Richard avait d'ailleurs eux ce réflexe d'ajouter (entier)
De PierreCitation:
de NuméroAuto vers Numérique (Entier).
Je suis bien d'accord avec ça. J'avais contourné le problème de l'intégrité référentielle en attribuant la clé primaire à mes numéros de document, seulement là où il était nécessaire que j'utilise la saisie via un formulaire avec sous-formulaire.Citation:
Je n'aime pas les clés primaires chargées de sens, dans la mesure ou si la signification change, patatra pour la suite.
Pour être plus précis, pour les pièces comptables, Facture de vente, Facture à l'entrée, et saisie des Financiers. Et là, ce n'est ni la coutume, ni la conformité comptable de changer un numéro de document.
Par contre, pour les articles, les clients, et les fournisseurs, j'ai utilisé les clés primaire Numéroauto, conscient que je suis que le changement d'adresse d'un tiers, l'ajout ou la suppression d'un blanc, l'adaptation d'une dénomination d'article, etc... me feraient perdre des données dans certaines lignes ou documents, avec une clé mal choisie.
Ma base de données fonctionne sans problème depuis 2 ans. Je la maîtrise avec beaucoup de facilité. Je n'y apporterai donc pas de modifications notables.
Pourtant, si je dois l'écrire de nouveau, ou en écrire une autre, sachant que je peux établir l'intégrité référentielle numéroauto -> numérique, je m'en tiendrai probablement aux méthodes conventionnelles.
Je vous remercie pour cette discussion éclairante, et espère que d'autres en profiteront.
Marcel
Le fait d'utiliser des clés primaires/externes uniquement informatiques n'empêche en rien d'utiliser des numéros de document attribués d'une autre manière.Citation:
Pour être plus précis, pour les pièces comptables, Facture de vente, Facture à l'entrée, et saisie des Financiers. Et là, ce n'est ni la coutume, ni la conformité comptable de changer un numéro de document.
Les clés primaires/externes ne servent que sur le plan informatique, et n'ont en fait rien à voir avec des numéros de documents. Comme le dit Fabien, l'utilisateur de la base ne verra jamais les clés primaires/externes et, s'il ne connaît pas Access, il ne se doutera même pas de leur existence.
Si tu dois exposer les lignes de détails d'une facture avec le numéro de facture, tu passeras alors par une requête utilisant les deux tables pour exposer certains champs de chaque table. Là encore, c'est transparent pour l'utilisateur qui verra le numéro du document et pas la clé utilisée par Access.
L'utilisation de clés purement informatiques permet de systématiser ton travail, car tu sais dans ce cas que toute clé primaire/externe est un entier long.
Citation:
Envoyé par Pierre Fauconnier
Merci beacoup pour aide .:ccool: