Discussion :

[fsmrel]

Bonsoir Elsa,

Je ne comprends pas tous les mots utilisé dans le cours "Numérotation personnalisée des enregistrements dans Access 2010"

Je pense que pour celui qui n’est pas rompu à VBA (Visual Basic for Applications) certaines formules peuvent paraître magiques, sinon hermétiques (remplacer alors le chocolat par de l’aspirine)...

Par où commencer? dois-je apprendre à programmer des macros avant toute choses?

Les macros, ça passe après la modélisation. Cela dit, connaissez-vous VBA ? SQL ? Avez-vous déjà utilisé des formulaires ACCESS ? (ou plus simplement, que connaissez-vous d’ACCESS ?) Avez-vous utilisé (en développement) d’autres SGBD qu’ACCESS ?

Dois-je revoir mes envies d'une belle base de données à la baisse (si ça devient trop complexe par rapport à mon expérience des bases de données en général et sous Access en particulier)?...

Pourquoi revoir à la baisse ? S’il le faut, on vous aidera à mettre tout ça œuvre. En compagnie de gens sympathiques et toujours prêts à rendre service comme Claude Leloup et f-leb, on devrait s’en sortir.

Quand considère-t-on qu'une modélisation est "terminée"?

La modélisation est achevée quand elle répond pleinement au besoin fonctionnel, c'est-à-dire quand on sait que la base de données qui en sera dérivée contiendra tous les éléments permettant de répondre aux questions (exprimées en bon français, ça suffira à ce stade) qu’on est susceptible de poser. La base de données est la réalisation physique du modèle, lequel est une abstraction, disons la définition de la machine abstraite dédiée à ses utilisateurs). Les besoins fonctionnels doivent être recensés dans le dossier de conception où figure le modèle. Considérons ces besoins comme des axiomes et le dossier comme leur corpus.

Bien entendu, un modèle n’est pas figé et doit pouvoir évoluer en fonction des besoins nouveaux des utilisateurs. Cela suppose que la fondation théorique soit robuste et saine...

Accessoirement, il est très vivement recommandé que la structure des tables réponde à ce qu’on appelle la forme normale de Boyce-Codd (BCNF), mais je ne voudrais pas vous traumatiser avec cette histoire qui a trait en fait aux redondances...

Faut il avoir tout prévu en terme de requête, formulaire et états?

Non ! Ces choses ne font pas partie des axiomes. Une requête n’est qu’un moyen langagier de consulter ou mettre à jour la base de données (je note en passant que ce qu’on appelle requête en ACCESS correspond à ce qu’on appelle vue dans la norme SQL et dans les SGBDR en général, et une vue n’est pas un axiome mais un théorème). Si une requête (au sens instruction SQL) n’est pas performante, on la réécrira, on mettra en place les index qui vont bien, etc. Si un formulaire n’est pas beau, ou est incomplet, on le retravaillera sans avoir besoin de modifier le corpus ! Un état n’est qu’un résultat, mais là encore on devra évidemment s’assurer que le corpus est complet.

Est-ce que les relations entre tables suffisent?

Les relations entre tables relèvent de l’intégrité des données, plus précisément de l’intégrité référentielle : une commande ne doit pas être orpheline, elle doit référencer un fournisseur présent dans la table FOURNISSEUR, sinon on est très mal. Même chose, pour les lignes de commande vis à vis des commandes et des références des fournisseurs, etc.

L’intégrité référentielle joue un rôle capital dans la robustesse et la crédibilité de la base de données. Cela dit, si les relations relèvent du modèle et y sont donc représentées, au stade de la réalisation elles doivent faire l’objet de l’intégrité référentielle, sous-traitée au SGBD (clés étrangères référençant les clés candidates pertinentes, cf. les images ci-dessous).

N'entre-t-on pas déjà dans le "comment" lorsque l'on cherche à faire de l'incrémentation relative?

On est évidemment au stade du comment, cet aspect des choses ne relève pas du modèle, mais de la réalisation.

je ne comprends pas bien ce qu'est un événement de table. J'ai bien l'impression que ça correspond en gros à ce que vous appelez un trigger mais c'est pas bien clair.

Manifestement il s’agit de la même chose. En fait, un trigger est un programme développé par nos soins, associé à une table, auquel le SGBD est prié de passer le relais quand se produit un événement (ajout, modification, suppression de lignes dans la table en question). Quand le trigger a fait ce qu’il avait à faire, il rend la main au SGBD. Ce qui est ballot avec ACCESS, c’est que pour les triggers, le jeu d’instructions est [beaucoup trop] réduit, je ne sais pas ce que leurs parents avaient dans le crâne pour nous fournir quelque chose d’aussi indigent (et contraignant dans la mise en œuvre)... En passant je rappelle ce que j’avais écrit précédemment (j’ai signalé son bogue à M. Microsoft, mais j’attends encore une réponse qui ne viendra sans doute jamais...) :

Heu... J'ai essayé les triggers (auxquels tu fais peut-être allusion). Avec SQL Server, DB2 et compagnie on s'en sort (assez ^^) facilement, mais avec ACCESS c'est un truc à vous rendre schizo, et en plus ça m’a tout l’air d’être bogué (au moins pour les triggers « Before »). Par exemple, dans le cas de l'insert, pour la ligne en cours, demandons-lui la valeur de la colonne FournisseurId de la table FOURNISSEUR : si {FournisseurId} est clé primaire, il ne renvoie rien (null), si {FournisseurId} n'est plus clé primaire, il fournit la valeur attendue... (Le problème ne se pose pas si on fait un update.) Faudra que je signale ça à M. Microsoft, à moins qu'un caïd du sérail comme Tofalu puisse nous éclairer à ce sujet.

Après ce moment de panique générale (un thé et un carré de chocolat plus tard), j'ai fait une tentative de mise en place des relations entre mes clés.

Allons-y avec calme et décontraction.

Etablissons l’association entre COMMANDE et LIGNE_COMMANDE, en nous situant dans les conditions initiales de température et de pression : COMMANDE et LIGNE_COMMANDE sont débranchées :





L’association doit être faite entre la clé primaire PKc = {FournisseurId, CommandeId} de la table COMMANDE et la paire FKg = {FournisseurId, CommandeId} de la table LIGNE_COMMANDE, paire considérée comme clé étrangère (chaque valeur de FKg doit d’abord être une valeur de PKc, intégrité référentielle oblige).

Pour brancher PKc et FKg, techniquement on sélectionne la paire {FournisseurId, CommandeId} de la table COMMANDE, puis on fait un « drag/drop » vers le cartouche intérieur de la table LIGNE_COMMANDE, ce qui provoque l’ouverture de la fenêtre « Edit Relationship » :




Reste à préciser à ACCESS de quoi est faite la clé étrangère FKg. On utilise la liste déroulante qui va bien (« Related Table/Query ») :



On met en correspondance les deux paires d’attributs (sans oublier de cocher la case « Enforce Referential Integrity ») :




Et quand on ferme la fenêtre « Edit Relationship » (bouton « Create), ô magie ! Les liens sont là :





Le principe est le même pour établir les associations entre FOURNISSEUR_REFERENCE et LIGNE_COMMANDE d’une part, et LIGNE_COMMANDE et OPTIQUE d’autre part.


Affaire à suivre, préparez le thé et l’aspirine (pour moi ça sera un Lagavulin bien tourbé)...

[Femtozaza]

Bonjour,
Merci pour ce calme et cette clarté, j'avoue un poil de panique hier!

J'ai compris tout ce qui est écrit, y compris les subtilités de fonctionnement du trigger/évènement.

Les macros, ça passe après la modélisation. Cela dit, connaissez-vous VBA ? SQL ? Avez-vous déjà utilisé des formulaires ACCESS ? (ou plus simplement, que connaissez-vous d’ACCESS ?) Avez-vous utilisé (en développement) d’autres SGBD qu’ACCESS ?

Je n'ai jamais programmé dans Access et n'ai jamais utilisé d'autres SGBD. Je connais VBA et SQL de nom.
J'avais déjà créé une base de données plus que basique (et pas très utilisable au quotidien, d'où mon souhait de faire quelque chose de propre et fini cette fois-ci) pour gérer le stock optique de mon ancien labo (c'est une manie chez moi hihi).
Quand à ce que je connais d'access, je me rend compte que ce n'est pas grand chose, et je me rends aussi compte de ses capacités et de celles des SGBD en général. Quand on sait ce qu'on veut et qu'on connait l'outil ça a l'air impressionnant.

Pourquoi revoir à la baisse ? S’il le faut, on vous aidera à mettre tout ça œuvre. En compagnie de gens sympathiques et toujours prêts à rendre service comme Claude Leloup et f-leb, on devrait s’en sortir.

Merci pour cette patience et cette générosité.

C'est là que je vous sers un verre de votre Whisky préféré et que je reprends un carré de chocolat (je reste au chocolat quand même).
Hier je n'arrivais pas à appliquer l'intégrité référentielle et à établir les relations entre les tables Fournisseur_References et Ligne_Commande... Ca devait être parce que j'essayais de faire correspondre directement les champs entre eux.... Enfin j'avais l'impression d'avoir fait pareil, mais c'est vrai que là ça marche, suis plus détendue qu'hier.

Merci pour ce pas à pas ^^. Voici le résultat:



Après ça il faut vérifier que les axiomes de départ correspondent à ce que nous venons de créer?

[fsmrel]

Bonsoir Elsa,


Le diagramme que vous proposez a une bonne tête. Reste à voir s’il est conforme au corpus des règles de gestion des données, énoncées dans dossier de conception des données...

Après ça il faut vérifier que les axiomes de départ correspondent à ce que nous venons de créer?

Of course... Ou plutôt, comme je viens de l’écrire, il faut vérifier que le diagramme est conforme au corpus des règles de gestion des données, lesquelles énumèrent, décrivent avec précision, et justifient les types d’entités et leurs attributs, ainsi que les relations entre types d’entités.

Les types d’entités donneront lieu au tables en ACCESS et les attributs aux champs (terme à utiliser en agriculture plutôt que dans le contexte des bases de données relationnelles, mais bon, les pères d’ACCESS n’ont pas été très regardants et n’ont pas dû lire Codd...)

Le dossier de conception devrait contenir l’inventaire (en français) des questions que l’on a l’intention de poser (au moins les plus importantes, à défaut des plus saugrenues), par exemple :

« Quel est le nom du fournisseur chez lequel on a acquis telle optique ?»

L’objectif est que, sur la base de cet inventaire, on s’assure que la structure de la base de données permette de répondre et qu’on n’ait pas à casser le beau modèle, mais seulement à le faire évoluer en douceur, si nécessaire, au fil des besoins qui se feront jour.

Je n'ai jamais programmé dans Access et n'ai jamais utilisé d'autres SGBD. Je connais VBA et SQL de nom.

Evidemment c’est handicapant...

Essayons déjà d’assurer un service minimum. Pour saisir les données,

1) Soit vous le faites directement dans les tables :



2) Soit vous utilisez SQL et créez une requête (en la nommant par exemple INSERT_INTO_FOURNISSEUR), ayant pour contenu :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
INSERT INTO FOURNISSEUR (FournisseurRef, FournisseurNom, FournisseuTel, FournisseurMail, FournisseurAdresseLigne2, FournisseurAdresseLigne3, FournisseurAdresseVille, FournisseurAdresseCPostal)
    VALUES ('F1', 'Volfoni Frères', '01 23 45 67 89', 'volfo@elsa.fr', '3, Quai des brumes', 'Péniche « Le grisbi »', 'Paris', '75020') ;

3) Soit vous utilisez un formulaire (j’utilise ici la notation anglaise, je vous laisse le soin d’adapter les termes en français).

Pour créer celui-ci, vous sélectionnez l’onglet « CREATE » et choisissez « Form Wizard » :



L’assistant vous propose de créer un formulaire pour la 1re table qu’il a sous la main :



Mais c’est la table FOURNISSEUR qui nous intéresse, on la sélectionne donc dans la combo « Tables/Queries » :



Après avoir fait « Next > » :



On transfère en une fois (bouton « >> ») l’ensemble des attributs dans « Selected Fields », on arrive à ceci :



Après avoir fait « Next > », il est demandé le type de représentation qu’on préfère :



Allons-y pour « Columnar », on donne ensuite un nom au formulaire et on demande à voir (bouton « Finish ») :



Manifestement, y a plus qu’à...




4) Soit vous utilisez VBA, mais il y a quelques prérequis..

A l’occasion de mon prochain message, on passe à la programmation...

[fsmrel]

Bonsoir Elsa,


Passons à la programmation ? Well! Revenons sur la question à poser à la base de données :

« Quel est le nom du fournisseur chez lequel on a acquis telle optique ?»

On peut se servir de SQL, VBA, ou de préférence de QBE (Query-By-Example), l’enfant d’un chercheur d’IBM (Moshé M. Zloof : “Query-By-Example” Proc. NCC 44, Anaheim Calif. (May 1975). Montvale, N.J. AFIPS Press (1977)).

En passant, QBE est fort bien présenté par C. J. Date dans An introduction to Database Systems, Third Edition, ISBN : 0201144395 (un trésor que l’on acquiert aujourd’hui pour environ 5 euros (port compris !), voyez par exemple chez AbeBooks).

Dans le contexte ACCESS, on construit ainsi la requête qui va bien :

Onglet « CREATE », choix : « Query Design » (je suis toujours avec la version en anglais) :





On a droit a cet écran sibyllin :





Au moyen de la fenêtre « Show Table », ACCESS nous demande de choisir les tables parties prenantes dans la requête. On recherche un nom de fournisseur, la table FOURNISSEUR est donc concernée. Comme la recherche met manifestement en cause l’attribut OptiqueNum de la table OPTIQUE, celle-ci est donc aussi concernée. Les autres tables permettent de « remonter » de la table OPTIQUE vers la table FOURNISSEUR, mais on n’a pas besoin d’elles, car l’attribut FournisseurId figure dans l’en-tête de la table OPTIQUE. On ne retient donc que ces deux tables :





En cliquant sur le bouton « Add », on voit apparaître les tables en question avec leurs attributs, ça peut aider pour la suite :






En fermant la fenêtre « show Table », on obtient ceci :






Revenons à la requête :

« Quel est le nom du fournisseur chez lequel on a acquis telle optique ? »

Pour la traduire en QBE, on fait figurer les attributs FournisseurNom et OptiqueNum, en précisant la valeur que doit prendre ce dernier (par exemple "opt03") :






A l’exécution de la requête, le résultat est le suivant :






Par curiosité, on demande à voir la requête au format SQL (Repasser en mode « Design View », et faire un clic droit dans la fenêtre) :





=>

Requête générée par ACCESS :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
SELECT OPTIQUE.OptiqueNum, FOURNISSEUR.FournisseurNom
FROM   FOURNISSEUR INNER JOIN OPTIQUE ON FOURNISSEUR.FournisseurId = OPTIQUE.FournisseurId
WHERE (((OPTIQUE.OptiqueNum)="opt03"));

Où l’on observe qu’il y a certes des parenthèses inutiles, mais surtout qu’ACCESS a su inférer la jointure nécessaire et suffisante entre les tables FOURNISSEUR et OPTIQUE pour la production d’un résultat correct.


Supposons maintenant que la question soit la suivante :

« Quel est le nom du fournisseur chez lequel on a acquis telle optique, ainsi que la référence chez icelui ? »

Faisons mention de la table FOURNISSEUR_REFERENCE (fenêtre « Show Tables », bouton « Add ») : ACCESS montre cette table dans la partie graphique, et la met automatiquement en relation avec la table FOURNISSEUR :





Ça sent le roussi, car ACCESS n’a pas inféré la jointure{FournisseurId, RefId} entre les tables OPTIQUE et FOURNISSSEUR_REFERENCE...

De fait, si on exécute la requête, on obtient l’ensemble des références du fournisseur, ce qui n’est pas le résultat attendu (on ne doit obtenir qu’une seule valeur pour l’attribut OptiqueNom) :





On va donc aider un peu ACCESS, en tirant les ficelles de FOURNISSSEUR_REFERENCE vers OPTIQUE dans la partie graphique (attributs FournisseurId et RefId), sans toucher ben sûr au beau modèle !






Cette fois-ci le résultat est conforme :




Ce que confirme SQL (je vous laisse le soin de vérifier, tablette de chocolat en main ) :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
SELECT OPTIQUE.OptiqueNum, FOURNISSEUR.FournisseurNom, FOURNISSEUR_REFERENCE.OptiqueNom
FROM   FOURNISSEUR_REFERENCE INNER JOIN (FOURNISSEUR INNER JOIN OPTIQUE 
       ON FOURNISSEUR.FournisseurId = OPTIQUE.FournisseurId) 
       ON (FOURNISSEUR.FournisseurId = FOURNISSEUR_REFERENCE.FournisseurId) 
          AND (FOURNISSEUR_REFERENCE.FournisseurId = OPTIQUE.FournisseurId) 
          AND  (FOURNISSEUR_REFERENCE.RefId = OPTIQUE.RefId)
WHERE (((OPTIQUE.OptiqueNum)="opt03"));

Bon, là-dessus, je vais me servir un verre de Lagavulin...

[Femtozaza]

Bonjour,

Merci merci pour tout ça!
Je vais faire la liste des questions de ce pas.
Une fois faite, j'essayerai de créer une requête qui va bien pour une de ces questions.
Je vous poste ça rapidement!

[fsmrel]

Bonjour Elsa,


Ne commencez surtout pas par les requêtes les plus compliquées, les plus lourdes, façon Alexeiev...



En tout cas, bon courage, même avec des barres à 10 kilos !

[Femtozaza]

Bon entre deux formations et réinstallation de notre installation (?!) j'ai essayé de m'y mettre mais c'est pas évident..
Je pense que je me bloque sur des bêtises.
La première chose à faire me semble être la mise en place de la saisie des données...

Devrais-je refaire un sujet dans une autre section du forum? Je devrai aussi lire un peu les autres sujets à ce sujet (?!)

Je vois probablement trop grand mais j'aurai aimé mettre en place un formulaire dynamique pour entrer mes données car lorsque j'entre les informations relative à une lentille, je n'ai que faire du taux de réflection par exemple.
De même j'aurai aimé mettre en place une numérotation automatique de mes optiques qui en donne les principales caractéristiques. Par exemple:

RMax-800-25-45-001 (serait un miroir Rmax à 800nm de diamètre 25mm optimisé pour un angle d'incidence de 45° et numéroté 001).

Peut-on plancher d'ores et déjà sur la réalisation de ce premier formulaire? Ou n'est-ce pas recommandé pour commencer?
Je pense que ça m'aidera à mieux comprendre, gérer où je ne sais pas trop comment dire (c'est un peu flou dans ma tête je dois dire), la relation requête/formulaire.

Merci d'avance en tout cas!

[Femtozaza]

Afin de m'aider à réfléchir sur ce fameux formulaire dynamique, j'ai réfléchis (je devrai peut-être arrêter?!) à ce que j'aimerai avoir, et voici en gros ce que ça donne:

L'idée serait de partir d'un "formulaire d'accueil" je vais dire.
En gros un affichage avec 3 boutons qui permettrait de diriger l'utilisateur vers le formulaire qui l'intéresse Pour simplifier, je vais donner des numéros à ce que j'appelle des formulaires pour le moment.

Formulaire1:

Info Optique: Affiche les informations pour une optique donnée (en fonction du numéro de l'optique)
Liste Optiques: Qui afficherai toutes les optiques correspondant à une ou plusieurs propriétés
Nouvelle optique: Permet d'entrer les informations d'une nouvelle optique dans la Base.

Je me concentre ensuite sur le cas "Nouvelle optique".
Je pensais, lorsque l'on clique sur ce bouton, faire ouvrir un formulaire demandant les informations suivantes:

Formulaire2:

N° de commande
Fournisseur
Réf fournisseur

Et qui une fois les infos données afficherait les caractéristiques (liées à la réf. Fournisseur) et le N° unique de l'optique implémenté à partir des caractéristiques choisies.
Donc 1ère question, comment utiliser la table LIGNE_COMMANDE créée précédemment?
2ème question: Est-il possible d'avoir un affichage en direct des caractéristique en fonction du choix de la réf. Fournisseur?

Dans ce formulaire2, l'idée serait:

• Si le fournisseur est connu: avoir la liste des références connues
• Si le fournisseur est inconnu: Ouvrir le formulaire fournisseur
• Si Réf. Fournisseur est inconnue: Ouvrir le formulaire Réf. Fournisseur

Nous aurions alors le formulaire3 qui serait le formulaire "Fournisseur", donnant les info fournisseur ( nom, adresse, tél, mèl, contact,...). Celui là il est facile à faire je pense.

Et le formulaire4: "Réf Fournisseur" qui ferait apparaître:

Réf. Fournisseur
Type d'optique (liste déroulante)

Lorsque le type d'optique serait choisi, ça ouvrirait un autre formulaire (formulaire5) qui permettrait de saisir les caractéristiques utiles pour ce type d'optique.

D'où la question finale de message: Cela est-il logique et réalisable?

Merci d'avance de vous pencher sur mon problème.

[fsmrel]

Bonsoir Elsa,

J'aurais aimé mettre en place une numérotation automatique de mes optiques qui en donne les principales caractéristiques. Par exemple:

RMax-800-25-45-001 (serait un miroir Rmax à 800nm de diamètre 25mm optimisé pour un angle d'incidence de 45° et numéroté 001).

Dans la mesure où la valeur «RMax-800-25-45-001 » est calculable à partir des éléments qui la composent, il n’est pas recommandé de la stocker « en dur » dans une colonne de table, on la présente à l’utilisateur à partir d’une colonne ad-hoc, mais qui fait référence à une fonction de calcul de la valeur. Exemple avec SQL Server :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
CREATE FUNCTION CalculIdentifiant(@A VARCHAR(64), @B INT, @C INT, @D INT, @E INT)
RETURNS VARCHAR(64)
AS
BEGIN  
  RETURN @A + '-' + CAST(@B AS VARCHAR(3)) + '-' + CAST(@C AS VARCHAR(3)) + '-' + CAST(@D AS VARCHAR(2)) + '-'+ CAST(@E AS VARCHAR(3)) ;
END ;
 
GO
 
CREATE table T 
(
  Nom              VARCHAR(32)  NOT NULL,
  Spec             INT          NOT NULL,
  Diametre         INT          NOT NULL,
  Angle            INT          NOT NULL,
  Numero           INT          NOT NULL,
  Identifiant AS dbo.CalculIdentifiant(Nom, Spec, Diametre, Angle, Numero)
) ;
 
GO
 
INSERT INTO T (Nom, Spec, Diametre, Angle, Numero) VALUES ('RMax', 800, 25, 45, 001);
 
SELECT * FROM T ;

Au résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Nom    Spec    Diametre    Angle    Numero    Identifiant
----   ----    --------    -----    ------    ----------------
RMax    800          25       45         1    RMax-800-25-45-1

Mais je ne sais pas si ACCESS propose l’instruction « CREATE FUNCTION »...


Pour vos formulaires (accueil et suivants), je pourrais probablement vous aider avec VBA, mais on rentre dans le monde de la programmation. Si vous connaissez VBA, tentons le coup, sinon il faudra en passer par les formulaires purs + QBE, mais là je ne me sens pas trop à l’aise : le mieux serait alors d’ouvrir une discussion à laquelle pourrait participer un champion des formulaires comme Claude Leloup.

Votre position ?

[f-leb]

Bonsoir,

Dans la mesure où la valeur «RMax-800-25-45-001 » est calculable à partir des éléments qui la composent, il n’est pas recommandé de la stocker « en dur » dans une colonne de table, on la présente à l’utilisateur à partir d’une colonne ad-hoc, mais qui fait référence à une fonction de calcul de la valeur [...]

Toutefois, il y a bien cette petite facilité apparue depuis Access 2010 avec un type de données « calculé » :

[fsmrel]

Il est quand même fort le Fabien ^^

[Femtozaza]

Merci pour vos réponses!

Alors, clairement en VBA je ne connais rien (à part le nom hihi), mais j'ai déjà fait un peu de programmation.
L'astuce de la numérotation par calcul de mes numéros d'optiques, c'est la solution parfaite effectivement. Juste un truc, est-il possible d'incrémenter le numéro automatiquement de façon conditionnelle (sur un ou plusieurs critères)? Car si j’ajoute une optique tous les mois, par exemple, je ne suis pas sûre d'être capable de me rappeler du dernier numéro de chaque type d'optique.

Pour mes autres questions j'ouvrirai un sujet dans la partie IHM du forum Access.
Merci pour tout en tout cas, ça m'a l'air bien parti!

[f-leb]

Bonjour,

Juste un truc, est-il possible d'incrémenter le numéro automatiquement de façon conditionnelle (sur un ou plusieurs critères)? Car si j’ajoute une optique tous les mois, par exemple, je ne suis pas sûre d'être capable de me rappeler du dernier numéro de chaque type d'optique.

Il faudrait préciser un peu mais tu peux regarder cette discussion, je crois que tu voudrais un truc sur le même principe.

[Femtozaza]

Merci pour le lien, effectivement ça peut marcher avec ça et si je ne me trompe pas ça peut aussi me servir pour numéroter mes RefId, CommandeId, et tout ça super.
Bon je ne sais pas encore comment ça marche mais je vais fouiller ^^
Merci!

[pyloupylou]

Ma foi, ça c'est de la formation.....

[Femtozaza]

Bonjour bonjour,

Vous m'aviez oublié? Moi pas!
Je me suis remise à donf sur ma base de données d'optique et je repasserai sur la partie IHM pour l'incrémentation au moment où j'en serai là.
Là j'avoue avoir fait un reset à ce sujet, j'espère que vous ne m'en voudrez pas trop

Je voulais juste vous tenir informé de l'ajout dans ma base de deux tables: Fabriquant et Référence_Fabriquant. En effet, je peux avoir plusieurs fournisseurs pour un même fabriquant. Donc pour me simplifier la vie (puisqu'il paraît que ça sert à ça les BDD ), j'ai ajouté ces deux tables.

Peut-être pourriez-vous jeter un œil sur le modèle amélioré avant que je continue avec un système qui serait trop merdique:



Merci d'avance, j'espère que je ne me suis pas trop loupée...