Discussion :

[kkaba]

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

[Pierre Fauconnier]

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.

[Marcello5255]

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

[f-leb]

Hello Marcello,

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.

Ben si on peut

Pour cette raison, et pour d'autres, je n'utilise plus jamais un champ numérauto comme clé primaire.

Allons bon! Pourquoi tant de haine envers le NumeroAuto

[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

[f-leb]

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"

bizarre, il n'y a pas de raison à première vue.

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.

Pour le point 1), tu pourrais joindre un bout de base en pièce-jointe ? Doit y avoir une boulette quelque part...

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

[kkaba]

Bonjour.


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.

Merci beacoup pour aide .