Bonjour et merci pour cette réponse ultra-rapide, pour le choix de cette structure de base c'est simplement que cette base existe déjà sur appleworks et que le but est de passer sur base pour pérenniser, or, la base appleworks avec toutes ces données a été "bidouillée" au fils des années, donc pour pourvoir utiliser les anciennes données et mettre à jour les nouvelles, cela me semblait pas trop mal comme compromis. mais effectivement la solution d'affichage d'un sous-formulaire me parait être la bonne solution (merci pour le lien) quitte à modifier les champs de table importée dans BASE. Mais, reste la question comment passer des valeurs de champ d'une table A à une table B..
>> Donc voici Problème : >> J'ai une table Communes avec les champs Communes, Cantons et Pays. >> Une autre table Données avec les champs Commune, canton, Nom bénéficiaire, >> Artisan1, Artisan2, Pays >> >> J'ai crée un formulaire avec une liste déroulante qui liste les champs >> 'Communes' de la table Commune et affecte de cette valeur le champ 'Commune' >> de la table Données. >> >> Jusqu'ici aucun problème >> J'aimerais aussi affecter en même temps les champs canton et Pays de la >> table Données par les valeurs correspondantes de la Commune. >> Bref, lorsque je choisi une commune dans la liste déroulante, que les >> champs canton et Pays de la table données soient mis à jour. >> >> Je pense qu'il faut utiliser une macro, qui se déclenche à l'évenement >> modifié de la listbox. >> Mais comment récupérer les valeurs correspondantes à une commune et >> comment les transférer d'une table à l'autre? >> >> J'avoue que je me perds dans toute la documentation macro.... Existe-t-il >> une méthode simple et assez commentée pour que je puisse réaliser cette >> macro, qui a priori ne devrait pas trop compliqué >> >> Vous trouverez en pièce jointe une version simplifiée de la base... >> Merci de votre aide, >> -- >> Stéphane >> > Bonjour, > > Avant que d'essayer d'apporter une réponse technique, je pense qu'il est > nécessaire de passer par une interrogation sur la conception de ta base. > > Dans la mesure où une commune n'est pas supposée changer de canton ni de > pays entre deux enregistrements, je ne vois pas quelle utilité peut exister > à stocker, dans la table Données, les informations relatives au canton et au > pays ; dès lors que tu as mentionné la commune pour un tuple de la table > Données, et dès lors que cette commune figure dans la table Communes, > l'information sur le canton et le pays du tuple concerné de la table Données > est connu, sans qu'il soit besoin de faire figurer ces informations dans la > table elle-même. > > Autrement dit, ces informations n'ont pas besoin d'être stockées dans la > table elle-même, l'intérêt de la base de données étant précisément de > récupérer l'information dans les différentes tables de la base, à l'instant > où on en a besoin et de fournir une information toujours "actualisée". > > Imagine que, en plus des informations mentionnées, ta table Communes > contienne une mention "Communauté de communes" ; imagine que, pour x ou y > raisons, une commune décide de quitter la communauté de commune dans > laquelle elle se trouvait jusqu'à présent pour en rejoindre une voisine ; > dans ton organisation, il faudrait modifier tous les enregistrements de ta > table Données qui comportent la commune concernée ; dans une table > normalement constituée, il suffit de modifier le contenu du champ > "Communauté de communes" de ta table Communes pour la commune concernée > (donc une seule modification) pour que cette modification soit prise en > compte lors de toutes les futures interrogations de ta base portant sur un > enregistrement affecté de cette commune. > > Maintenant, tu vas me dire, que c'est bien beau tout ça, mais que toi, tu > as besoin de ressortir dans un formulaire ou un publipostage, les > informations relatives au canton et au pays de chaque enregistrement de la > table Données ; aucune difficulté, c'est le boulot des bases de données ; > pour un formulaire, il te suffit de créer un formulaire et un > sous-formulaire (dans le même document), dans un premier temps au moyen de > l'assistant pour découvrir les bases, ensuite par tes propres moyens (tu > verras que 'on peut créer de cette façon, des sous-sous-formulaires ainsi > que des sous-sous-sous-formulaires, et ainsi de suite) ; au besoin, tu > pourras te replonger dans les archives de cette liste dans lesquelles > doivent figurer les traces d'une longue discussion que j'ai eue l'été > dernier sur ce même propos (ça doit même être là > http://fr.openoffice.org/servlets/ReadMsg?list=users&msgNo=72049) ; il est > possible que tu en tires quelques informations ; pour un publipostage, il te > faudra écrire une requête combinant les deux tables (c'est relativement > simple) et établir ton publipostage sur cette requête ; au besoin, tu > pourras même générer une table à partir des résultats de ta requête (cette > table se mettra à jour constamment, en fonction de l'évolution des tables > Communes et Données). > > A+ > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Stéphane Feray // graphiste - plasticien // http://www.stephane-feray.fr
