Débutant Access difficultés de mise en œuvre de solution

Bonsoir,

Tu es manifestement un faux débutant et sans doute en connais-tu bien plus que moi sur les BD en dehors de Access.

Autant dire tout de suite que j'ai pas pu lire ni ton extrait de formulaire ni tes expressions de SQL. Question de taille des caractères. Je répondrai donc un  peu à l'aveuglette à ta question.

Il me semble que, compte tenu de ta demande, le mieux serait d'avoir en pied de formulaire un contrôle "Solde" ou "EtatDuStock" qui reprenne les expressions "DSum("xxx","yyy","zzz")" en entrées et en sorties, où,  "xxx" est la variable à rechercher, en l'occurrence les quantités,  "yyy" la table ou la requête dans lesquelles les données sont disponibles, et "zzz" l'équation qui valide les critères de sélection des données "xxx" à recueillir.

Dans tous les cas, n'hésite surtout pas  consulter l'aide de MS-Access, qui n'est pas trop mal fait même s'il est beaucoup moins de celui présenté il y a longtemps déjà.

Bon courage.

Bonjour Tessel75,

Merci pour ta réponse.

En cliquant sur mes pièces jointes, elles s'ouvrent et elles deviennent lisibles.

Si tu peux y jeter un œil.

Merci 

Bonne journée

bonjour,

Tu pourrais créer une requête qui calculerait le stock, puis utiliser, comme source du formulaire, cette requête au lieu de la table.

Bonjour YG_BE

Merci de tes réponses.

Concernant ta remarque sur la pièce jointe de code, merci de me le faire remarquer, j'en tiendrais compte lors de mes prochains posts.

Concernant des deux autres remarques (Dates et Sum), ce n'est pas moi qui ait écrit ces codes, je les hérite du développeur de l'embryon de l'application. Pour les Dates, j'ai cru comprendre que c'était à cause du format Anglais des Dates. Mais je vais essayer sans format pour voir si ça passe. Le module mFonctions est utilisé pour afficher le stock actuel dans les formulaires de gestion des Entrées et de Sorties de Stock.

S'agissant de ta proposition, j'y ai pensé , mais mon formulaire est un formulaire de mise à jour de la table Articles et non de consultation.

Et précision supplémentaire, mon Stock est contenu dans mes tables Entrées et Sorties en faisant la somme des Entrées - la somme des Sorties, et ces tables ne font pas partie de mon formulaire

D'ailleurs, je m'aperçois que dans mon code la donnée (tArticleFk) qui permet de cibler les enregistrements concernées dans les 2 tables Entrées et Sorties ne correspond pas à ma donnée tArticlesPk de mon formulaire (normal puisqu'il est utilisé à l'origine pour les tables tEntrees et tSorties)

Question subsidiaire : un module public mFonctions peut-il être appelé de n'importe où dans l'application ou il est forcément lié à un objet ?

En fait, ce que j'aurais voulu faire, c'est créer un objet de classe pour ce champ Stock_actuel de mon formulaire, mais je ne vois pas comment aller lire des tables extérieures au formulaire généré. (en Cobol ou sur Oracle cela aurait été fait en 2, 4 6 ...)

J'ai beau naviguer dans l'aide en ligne d'Access, sur les tutos accessibles , mais je ne trouve pas grand chose qui puisse m'aider

Merci pour ton aide yg_be.

Philippe

Bonjour à tous les deux,

Pour répondre à ta question et aux remarques de Yebe, je pense qu'il vaut toujours bien mieux avoir des fonctions publiques dans ton code, ce qui te permet de les appeler chaque fois que tu en as besoin sans t'occuper de savoir si tu l'entres sur un formulaire, un sous-formulaire ou un état ou autre.

Après, pour ce qui est des mises à jours des données, tu as bien sûr intérêt à avoir une requête qu'on puisse mettre à jour (requête-sélection) pour ton formulaire, et comme je le disais à ma 1ère réponse, mettre en affichage le solde en pied de formulaire avec les fonctions DSum("xxx","yyy","zzz") , et qui s'actualise automatiquement par simple click, ou lorsque tu sors d'un formulaire.

Par exemple, pour moi j'ai un formulaire de ce type pour compter le solde de mon compte bancaire. J'ai un formulaire avec l'intitulé du compte et en sous-formulaire les entrées et les sorties d'argent, et en pied de formulaire principal le solde avec les fameuses fonctions DSum () qui s'actualisent quand je rentre un débit ou un crédit.

Bonne suite

Merci de ton retour rapide

1- ce que j'appelle Objet est un formulaire ou un champ d'un formulaire

2- Oui, c'est bien un formulaire généré avec l'assistant qui me sert à mettre à jour ma table (Ajout, Suppression, MAJ) et basé sur la table Articles

3 - Si je te suis , dans un formulaire généré sur une table, d'autres tables ne peuvent pas intervenir même dans une procédure "Private Sub" lié à un champ de mon formulaire

4 - Il faudrait donc passer par un Formulaire construit sans association à une table particulière, en développant entièrement tout le code lié . ce qui me permettrait d'accéder à n Tables . (Pas simple à faire pour un débutant sous Access)

A te lire

Bonsoir Tessel75,

1 - Pour appeler une fonction c'est bien l'ordre Call NomdelaForme.fnc_NomdelaFonction introduite dans un Private Sub ?

2 - Je vois ce que tu veux dire. 

En fait tu as une Table Maître "compte bancaire" avec une ou des Tables Détail "opérations sur le compte" en débit ou en crédit. Ton formulaire est basé sur la table Maître et ton sous-formulaire sur la ou les tables Détails.

J'ai deux formulaires un peu comme celui-ci que j'ai hérité de l'application d'origine, mais la Table Maître n'est pas impliquée. Ces formulaires gèrent les entrées et les sorties de stock.

Mon contexte, par analogie par rapport à ta Gestion de compte, c'est comme si tu avais plusieurs comptes bancaires dans ta Table Maître et que tu faisais un formulaire lié à cette Table Maître pour avoir pour chacun des comptes les infos du compte (Nom banque, No compte, ect ...) ainsi que les soldes de chacun des comptes .

Comment tu t'y prendrais pour créer ça ?

Re-Bonjour,

Tu as tout compris. En fait, je voulais construire une base générale pouvant servir à une famille avec plusieurs personnes, plusieurs banques et plusieurs comptes.

Je pensais que mon exemple pourrait te servir pour ta gestion de stocks de bois, avec plusieurs essences et éventuellement plusieurs coupes. Pour ce tu dis, l'idée est bien là.

Pour détailler.

J'ai une petite table Nom ,  par ex Propriété

une table  Prénom  =>  Parcelle d'origine

une table  Banque =>  par ex  :  type Bois

une table  N° Compte =>  coupe

une table  Débit/Crédit =>  Entrée/Sortie quantité

Bon courage.

Bonjour,

Merci à Tessel75 et Yg_Be pour leurs interventions et leur aide.

J'ai mis le week-end à profit pour fouiller ACCESS

Bonne Journée