Discussion :

[Jkv.W4L]

Bonjour,
Pour ce 1er message, je vais essayer d'être aussi clair que possible :
Pour re-situer le contexte, dans le cadre de mes études, je crée une base de données sur un S.A.V, j'ai donc deux tables pour gérer les grilles de forfait de main d'oeuvre et les pièces utilisées, qui sont reliées à une troisième intitulé très originalement réparation.

J'utilise donc, la fonction champ calculé pour faire une somme dans cette table "réparation", le problème est que le calcul ne s'effectue pas du fait que les champs ajoutés contiennent plusieurs "objets" (n° pièce, nom pièce, prix pièce).

J'aimerai donc savoir s'il était possible de choisir quel "objet" peut être pris en compte par le champ calculé.
J'ai déjà essayé de changer le champ "colonne liée" dans la propriété du champ "pièce", mais rien n'y fait, toujours pas de calcul.

Mon prof m'a suggéré de recréer une table où chaque réparation serait représentée avec le nombre de pièces utilisées et le forfait de main d'oeuvre, mais j'ai pas du tout saisir, et je trouve le processus un peu compliqué, comparé au champ calculé qui serait parfait au niveau de la simplicitié d'utilisation.

[rjamin]

Bonjour,

Il faut créer les relations entre les tables, puis créer une requête en utilisant les 3 tables et là vous tous les champs disponibles pour créer le champ calculé que vous voulez.

Voyez dans la FAQ du site et chercher un peu les renseignements sur la réalisation des relations entre tables et la création de champs calculés.

RJ

[Jeannot45]

Il y a un chapitre sur les nouveautés d'Access 2010 qui pourrait t'ouvrir une piste : Les triggers (les déclencheurs)

bonne lecture et bonne continuation

[Tofalu]

A noter aussi ce document :

Les bonnes pratiques de la programmation des macros de données
http://warin.developpez.com/tutoriel...nements-table/

III. Modélisation
Les évènements de table introduits avec Microsoft Access 2010 permettent de mettre en place la quasi-totalité des traitements qu'il est possible de faire subir à un jeu de données. Ils peuvent être utilisés pour valider la saisie de l'utilisateur (nous verrons cette partie au chapitre suivant) ou bien pour transposer la saisie dans une autre structure en y appliquant des règles de gestion jusque-là confiées à VBA via un formulaire. Comme pour chaque nouveauté Access, le public utilisateur peut être divisé en 3 catégories :


•Les récalcitrants : ils n'utiliseront jamais les évènements de table, persuadés qu'ils sont peu fiables ou inutiles bien qu'ils fassent partie de ceux qui les ont réclamés pendant longtemps.
•Les utilisateurs avertis : ils connaissent la fonctionnalité et savent en tirer profit.
•Les novices : ils viennent de découvrir la nouveauté et ont besoin de parfaire leurs connaissances avant de la mettre en place dans un cadre professionnel.

C'est justement à cette troisième catégorie que ce document, et plus particulièrement ce chapitre, est adressé. En effet, si tous les autres chapitres tiennent plus de l'optimisation et du perfectionnement d'une base, celui-ci et dans une moindre mesure le suivant, seront les garants d'une application stable, robuste, évolutive et maintenable.


Le principal risque réside dans une dénormalisation de la structure de la base. Celle-ci pourra être « volontaire » (le concepteur a sciemment ignoré les règles) ou « involontaire » (les maintenances successives et le recours systématique aux évènements de table ont conduit à des duplications de structure faisant du projet une véritable usine à gaz)

En d'autres termes, si vous débutez, passez votre chemin et créez une base normalisée.