Bonjour,
j'ai créé une table paramètres avec un champ employé. Il y a plusieurs
employés avec chacun un code qui doivent effectuer diverses entrées dans une
table. Dans cette table, en plus d'autres variables, il y a bien sûr le champ
employé. Je voudrais que ce champ s'enregistre automatiquement pour chacune
des entrées effectuées par cet employé. Le code de l'employé s'affiche
présentement, mais ne s'enregistre pas dans la table.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Daniel
Salut J. Pierre, Je ne suis pas sûr d'avoir tout saisi, mais il me semble que la solution à ton problème se situe autour de la notion de sous-formulaire... Par exemple : sur un formulaire principal des Employés, un sous-formulaire permet de gérer automatiquement les enregistrements liés dans une table Variables ... Et vice-versa si nécessaire... A+ Daniel
Salut J. Pierre,
Je ne suis pas sûr d'avoir tout saisi, mais il me semble que la solution à
ton problème se situe autour de la notion de sous-formulaire...
Par exemple : sur un formulaire principal des Employés, un sous-formulaire
permet de gérer automatiquement les enregistrements liés dans une table
Variables ... Et vice-versa si nécessaire...
A+ Daniel
Salut J. Pierre, Je ne suis pas sûr d'avoir tout saisi, mais il me semble que la solution à ton problème se situe autour de la notion de sous-formulaire... Par exemple : sur un formulaire principal des Employés, un sous-formulaire permet de gérer automatiquement les enregistrements liés dans une table Variables ... Et vice-versa si nécessaire... A+ Daniel
J.Pierre
Salut Daniel et merci pour ta réponse. Je vais lire la documentation sur les sous-formulaire. Pour préciser mon problème, je pourrais ajouter ce qui suit: Lors de la définition d'un champ dans une table, nous pouvons, via liste de choix, effectuer ce choix dans une table quelconque. Ce que je voudrais faire est d'utiliser ce choix et de le placer comme valeur par défaut dans la table.
Merci!
Jean-Pierre
"Daniel" a écrit :
Salut J. Pierre, Je ne suis pas sûr d'avoir tout saisi, mais il me semble que la solution à ton problème se situe autour de la notion de sous-formulaire... Par exemple : sur un formulaire principal des Employés, un sous-formulaire permet de gérer automatiquement les enregistrements liés dans une table Variables ... Et vice-versa si nécessaire... A+ Daniel
Salut Daniel et merci pour ta réponse. Je vais lire la documentation sur les
sous-formulaire.
Pour préciser mon problème, je pourrais ajouter ce qui suit:
Lors de la définition d'un champ dans une table, nous pouvons, via liste de
choix, effectuer ce choix dans une table quelconque. Ce que je voudrais faire
est d'utiliser ce choix et de le placer comme valeur par défaut dans la table.
Merci!
Jean-Pierre
"Daniel" a écrit :
Salut J. Pierre,
Je ne suis pas sûr d'avoir tout saisi, mais il me semble que la solution à
ton problème se situe autour de la notion de sous-formulaire...
Par exemple : sur un formulaire principal des Employés, un sous-formulaire
permet de gérer automatiquement les enregistrements liés dans une table
Variables ... Et vice-versa si nécessaire...
A+ Daniel
Salut Daniel et merci pour ta réponse. Je vais lire la documentation sur les sous-formulaire. Pour préciser mon problème, je pourrais ajouter ce qui suit: Lors de la définition d'un champ dans une table, nous pouvons, via liste de choix, effectuer ce choix dans une table quelconque. Ce que je voudrais faire est d'utiliser ce choix et de le placer comme valeur par défaut dans la table.
Merci!
Jean-Pierre
"Daniel" a écrit :
Salut J. Pierre, Je ne suis pas sûr d'avoir tout saisi, mais il me semble que la solution à ton problème se situe autour de la notion de sous-formulaire... Par exemple : sur un formulaire principal des Employés, un sous-formulaire permet de gérer automatiquement les enregistrements liés dans une table Variables ... Et vice-versa si nécessaire... A+ Daniel
Daniel
Salut Jean-Pierre,
C'est vrai qu'Access fournit cette possibilité, mais honnêtement, je lui ai toujours préféré de beaucoup une autre solution : - une table des valeurs par défaut, contenant un seul enregistrement, et un champ pour pratiquement chaque liste déroulante de l'application; - un formulaire des valeurs par défaut, chacune choisie dans une liste déroulante basée sur la table concernée... - dans chaque liste déroulante de l'application où une valeur par défaut est attendue, on la renseigne avec un simple et rapide RechDom (exemple : =rechdom("[D_Ville]";"[Valeurs_Défaut]")...).
C'est donc l'utilisateur qui choisira quelles valeurs par défaut il souhaite avoir à la création d'un enregistrement... L'avantage est que bien sûr, tu pourras appliquer l'intégrité référentielle les yeux fermés, puisque le choix dans la liste sera obligatoire...
Exemple classique : une adresse complète... Si tes adresses sont presque toutes situées à Paris, tu as intérêt à ce que la valeur par défaut soit Paris. Mais si d'un coup tu transposes ton application à Marseille, il ne faut pas que tu sois obligé d'intervenir sur la structure de ta base pour modifier la valeur par défaut. Il suffira d'aller modifier la valeur dans le formulaire des valeurs par défaut.
L'exemple de la ville peut sembler tiré par les cheveux, mais si on passe en revue toutes les valeurs par défaut dont on a besoin dans une application, l'utilité d'une telle table n'est plus à démontrer, sauf à se passer des valeurs par défaut...
Voilà, j'espère avoir pu t'aider A+ Daniel
Salut Jean-Pierre,
C'est vrai qu'Access fournit cette possibilité, mais honnêtement, je lui ai
toujours préféré de beaucoup une autre solution :
- une table des valeurs par défaut, contenant un seul enregistrement, et un
champ pour pratiquement chaque liste déroulante de l'application;
- un formulaire des valeurs par défaut, chacune choisie dans une liste
déroulante basée sur la table concernée...
- dans chaque liste déroulante de l'application où une valeur par défaut est
attendue, on la renseigne avec un simple et rapide RechDom (exemple :
=rechdom("[D_Ville]";"[Valeurs_Défaut]")...).
C'est donc l'utilisateur qui choisira quelles valeurs par défaut il souhaite
avoir à la création d'un enregistrement...
L'avantage est que bien sûr, tu pourras appliquer l'intégrité référentielle
les yeux fermés, puisque le choix dans la liste sera obligatoire...
Exemple classique : une adresse complète... Si tes adresses sont presque
toutes situées à Paris, tu as intérêt à ce que la valeur par défaut soit
Paris. Mais si d'un coup tu transposes ton application à Marseille, il ne
faut pas que tu sois obligé d'intervenir sur la structure de ta base pour
modifier la valeur par défaut. Il suffira d'aller modifier la valeur dans le
formulaire des valeurs par défaut.
L'exemple de la ville peut sembler tiré par les cheveux, mais si on passe en
revue toutes les valeurs par défaut dont on a besoin dans une application,
l'utilité d'une telle table n'est plus à démontrer, sauf à se passer des
valeurs par défaut...
C'est vrai qu'Access fournit cette possibilité, mais honnêtement, je lui ai toujours préféré de beaucoup une autre solution : - une table des valeurs par défaut, contenant un seul enregistrement, et un champ pour pratiquement chaque liste déroulante de l'application; - un formulaire des valeurs par défaut, chacune choisie dans une liste déroulante basée sur la table concernée... - dans chaque liste déroulante de l'application où une valeur par défaut est attendue, on la renseigne avec un simple et rapide RechDom (exemple : =rechdom("[D_Ville]";"[Valeurs_Défaut]")...).
C'est donc l'utilisateur qui choisira quelles valeurs par défaut il souhaite avoir à la création d'un enregistrement... L'avantage est que bien sûr, tu pourras appliquer l'intégrité référentielle les yeux fermés, puisque le choix dans la liste sera obligatoire...
Exemple classique : une adresse complète... Si tes adresses sont presque toutes situées à Paris, tu as intérêt à ce que la valeur par défaut soit Paris. Mais si d'un coup tu transposes ton application à Marseille, il ne faut pas que tu sois obligé d'intervenir sur la structure de ta base pour modifier la valeur par défaut. Il suffira d'aller modifier la valeur dans le formulaire des valeurs par défaut.
L'exemple de la ville peut sembler tiré par les cheveux, mais si on passe en revue toutes les valeurs par défaut dont on a besoin dans une application, l'utilité d'une telle table n'est plus à démontrer, sauf à se passer des valeurs par défaut...
Voilà, j'espère avoir pu t'aider A+ Daniel
J.Pierre
Bonjour Daniel,
je te remercie énormément pour le temps consacré ¸a mon problème. J'ai suivi tes recommandations et j'ai défini 3 tables dans mon application. L'application est en fait un petit système qui a pour fonction de cumuler des dons pour des gens afin d'émettre des reçus à la fin de l'année. Les entrées sont effectuées par 4 bénévoles.
Les 3 tables que j'ai établies sont les suivantes:
[Paramètre bénévole] ayant comme unique champ Bénévole [Bénévoles] ayant comme champs ID (code de 3 lettres) et Nom (Nom du bénévole) [Contribution] ayant comme champs NO (No de l'enveloppe contenant la contribution), Montant (Montant du don), Date (Date du don), et finalement Code bénévole (qui doit avoir comme valeur celle donnée à Bénévole dans la table [Paramètre bénévole]
Dans le formulaire d'entrée des dons, le champ Code bénévole de la table [Contribution] a comme contenu ce qui suit: SELECT [Paramètre bénévole].Bénévole FROM [Paramètre bénévole];
De plus, comme valeur par défaut, j'ai inscrit =RechDom("Code Bénévole]";"[Paramètre bénévole]")
Lorsque j'essaie d'entrer des données, ça me donne #erreur.
J'ai beau vérifier la syntaxe, mais je ne vois rien. Il y a peut être quelque chose que je n'ai pas compris dans ta suggestion.
Merci beaucoup de ton aide.
Jean-Pierre "Daniel" a écrit :
Salut Jean-Pierre,
C'est vrai qu'Access fournit cette possibilité, mais honnêtement, je lui ai toujours préféré de beaucoup une autre solution : - une table des valeurs par défaut, contenant un seul enregistrement, et un champ pour pratiquement chaque liste déroulante de l'application; - un formulaire des valeurs par défaut, chacune choisie dans une liste déroulante basée sur la table concernée... - dans chaque liste déroulante de l'application où une valeur par défaut est attendue, on la renseigne avec un simple et rapide RechDom (exemple : =rechdom("[D_Ville]";"[Valeurs_Défaut]")...).
C'est donc l'utilisateur qui choisira quelles valeurs par défaut il souhaite avoir à la création d'un enregistrement... L'avantage est que bien sûr, tu pourras appliquer l'intégrité référentielle les yeux fermés, puisque le choix dans la liste sera obligatoire...
Exemple classique : une adresse complète... Si tes adresses sont presque toutes situées à Paris, tu as intérêt à ce que la valeur par défaut soit Paris. Mais si d'un coup tu transposes ton application à Marseille, il ne faut pas que tu sois obligé d'intervenir sur la structure de ta base pour modifier la valeur par défaut. Il suffira d'aller modifier la valeur dans le formulaire des valeurs par défaut.
L'exemple de la ville peut sembler tiré par les cheveux, mais si on passe en revue toutes les valeurs par défaut dont on a besoin dans une application, l'utilité d'une telle table n'est plus à démontrer, sauf à se passer des valeurs par défaut...
Voilà, j'espère avoir pu t'aider A+ Daniel
Bonjour Daniel,
je te remercie énormément pour le temps consacré ¸a mon problème. J'ai suivi
tes recommandations et j'ai défini 3 tables dans mon application.
L'application est en fait un petit système qui a pour fonction de cumuler des
dons pour des gens afin d'émettre des reçus à la fin de l'année. Les entrées
sont effectuées par 4 bénévoles.
Les 3 tables que j'ai établies sont les suivantes:
[Paramètre bénévole] ayant comme unique champ Bénévole
[Bénévoles] ayant comme champs ID (code de 3 lettres) et Nom (Nom du bénévole)
[Contribution] ayant comme champs NO (No de l'enveloppe contenant la
contribution), Montant (Montant du don), Date (Date du don), et finalement
Code bénévole (qui doit avoir comme valeur celle donnée à Bénévole dans la
table [Paramètre bénévole]
Dans le formulaire d'entrée des dons, le champ Code bénévole de la table
[Contribution] a comme contenu ce qui suit: SELECT [Paramètre
bénévole].Bénévole FROM [Paramètre bénévole];
De plus, comme valeur par défaut, j'ai inscrit =RechDom("Code
Bénévole]";"[Paramètre bénévole]")
Lorsque j'essaie d'entrer des données, ça me donne #erreur.
J'ai beau vérifier la syntaxe, mais je ne vois rien. Il y a peut être
quelque chose que je n'ai pas compris dans ta suggestion.
Merci beaucoup de ton aide.
Jean-Pierre
"Daniel" a écrit :
Salut Jean-Pierre,
C'est vrai qu'Access fournit cette possibilité, mais honnêtement, je lui ai
toujours préféré de beaucoup une autre solution :
- une table des valeurs par défaut, contenant un seul enregistrement, et un
champ pour pratiquement chaque liste déroulante de l'application;
- un formulaire des valeurs par défaut, chacune choisie dans une liste
déroulante basée sur la table concernée...
- dans chaque liste déroulante de l'application où une valeur par défaut est
attendue, on la renseigne avec un simple et rapide RechDom (exemple :
=rechdom("[D_Ville]";"[Valeurs_Défaut]")...).
C'est donc l'utilisateur qui choisira quelles valeurs par défaut il souhaite
avoir à la création d'un enregistrement...
L'avantage est que bien sûr, tu pourras appliquer l'intégrité référentielle
les yeux fermés, puisque le choix dans la liste sera obligatoire...
Exemple classique : une adresse complète... Si tes adresses sont presque
toutes situées à Paris, tu as intérêt à ce que la valeur par défaut soit
Paris. Mais si d'un coup tu transposes ton application à Marseille, il ne
faut pas que tu sois obligé d'intervenir sur la structure de ta base pour
modifier la valeur par défaut. Il suffira d'aller modifier la valeur dans le
formulaire des valeurs par défaut.
L'exemple de la ville peut sembler tiré par les cheveux, mais si on passe en
revue toutes les valeurs par défaut dont on a besoin dans une application,
l'utilité d'une telle table n'est plus à démontrer, sauf à se passer des
valeurs par défaut...
je te remercie énormément pour le temps consacré ¸a mon problème. J'ai suivi tes recommandations et j'ai défini 3 tables dans mon application. L'application est en fait un petit système qui a pour fonction de cumuler des dons pour des gens afin d'émettre des reçus à la fin de l'année. Les entrées sont effectuées par 4 bénévoles.
Les 3 tables que j'ai établies sont les suivantes:
[Paramètre bénévole] ayant comme unique champ Bénévole [Bénévoles] ayant comme champs ID (code de 3 lettres) et Nom (Nom du bénévole) [Contribution] ayant comme champs NO (No de l'enveloppe contenant la contribution), Montant (Montant du don), Date (Date du don), et finalement Code bénévole (qui doit avoir comme valeur celle donnée à Bénévole dans la table [Paramètre bénévole]
Dans le formulaire d'entrée des dons, le champ Code bénévole de la table [Contribution] a comme contenu ce qui suit: SELECT [Paramètre bénévole].Bénévole FROM [Paramètre bénévole];
De plus, comme valeur par défaut, j'ai inscrit =RechDom("Code Bénévole]";"[Paramètre bénévole]")
Lorsque j'essaie d'entrer des données, ça me donne #erreur.
J'ai beau vérifier la syntaxe, mais je ne vois rien. Il y a peut être quelque chose que je n'ai pas compris dans ta suggestion.
Merci beaucoup de ton aide.
Jean-Pierre "Daniel" a écrit :
Salut Jean-Pierre,
C'est vrai qu'Access fournit cette possibilité, mais honnêtement, je lui ai toujours préféré de beaucoup une autre solution : - une table des valeurs par défaut, contenant un seul enregistrement, et un champ pour pratiquement chaque liste déroulante de l'application; - un formulaire des valeurs par défaut, chacune choisie dans une liste déroulante basée sur la table concernée... - dans chaque liste déroulante de l'application où une valeur par défaut est attendue, on la renseigne avec un simple et rapide RechDom (exemple : =rechdom("[D_Ville]";"[Valeurs_Défaut]")...).
C'est donc l'utilisateur qui choisira quelles valeurs par défaut il souhaite avoir à la création d'un enregistrement... L'avantage est que bien sûr, tu pourras appliquer l'intégrité référentielle les yeux fermés, puisque le choix dans la liste sera obligatoire...
Exemple classique : une adresse complète... Si tes adresses sont presque toutes situées à Paris, tu as intérêt à ce que la valeur par défaut soit Paris. Mais si d'un coup tu transposes ton application à Marseille, il ne faut pas que tu sois obligé d'intervenir sur la structure de ta base pour modifier la valeur par défaut. Il suffira d'aller modifier la valeur dans le formulaire des valeurs par défaut.
L'exemple de la ville peut sembler tiré par les cheveux, mais si on passe en revue toutes les valeurs par défaut dont on a besoin dans une application, l'utilité d'une telle table n'est plus à démontrer, sauf à se passer des valeurs par défaut...
Voilà, j'espère avoir pu t'aider A+ Daniel
Daniel
Comme ça, sans avoir le temps de beaucoup détailler, je dirais que ton problème pourrait être résolu facilement à l'aide d'un formulaire Contributions, basé sur une table du même nom (la tienne est presque OK), avec, pour renseigner le bénévole, une liste déroulante qui va piocher dans la table Bénévoles...
La correction la plus importante, c'est cette table Bénévoles : pourquoi 2 tables là où une seule suffit ? Exemple de structure : - B_Code : numéroAuto, clé - B_Nom : texte de xx caractères
La table Contributions : - C_Code : numéroAuto, Clé - C_Bénévole : Entier, indexé avec doublons - C_Montant : monétaire - C_Date : Date
L'idéal serait de définir en dur la relation Bénévoles.B_Code <-> Contributions.C_Bénévole, et d'appliquer l'intégrité référentielle, de manière à éviter les contributions sans bénévole...
Les caractéristiques de la liste déroulante C_Bénévole sur le formulaire Contributions : - source : une requête contenant Bénévoles.B_Code, Bénévoles.B_Nom, triée sur B_Nom - nombre de colonnes : 2 - largeurs des colonnes : 0;8 cm - colonne liée : 1 - valeur par défaut : =mindom("[B_Nom]";"[Bénévoles]")
Acces va automatiquement stocker l'index du bénévole choisi dans la liste pour la contribution courante... Et par défaut, tu auras le premier nom par ordre alpha affiché dans ta liste...
Tout ce que je t'ai dit sur la gestion des valeurs par défaut précédemment ne concerne pas tout à fait ce cas de figure... Mais on peut en reparler lundi ! Bonne soirée et bon week-end ! Daniel
Comme ça, sans avoir le temps de beaucoup détailler, je dirais que ton
problème pourrait être résolu facilement à l'aide d'un formulaire
Contributions, basé sur une table du même nom (la tienne est presque OK),
avec, pour renseigner le bénévole, une liste déroulante qui va piocher dans
la table Bénévoles...
La correction la plus importante, c'est cette table Bénévoles : pourquoi 2
tables là où une seule suffit ? Exemple de structure :
- B_Code : numéroAuto, clé
- B_Nom : texte de xx caractères
La table Contributions :
- C_Code : numéroAuto, Clé
- C_Bénévole : Entier, indexé avec doublons
- C_Montant : monétaire
- C_Date : Date
L'idéal serait de définir en dur la relation Bénévoles.B_Code <->
Contributions.C_Bénévole, et d'appliquer l'intégrité référentielle, de
manière à éviter les contributions sans bénévole...
Les caractéristiques de la liste déroulante C_Bénévole sur le formulaire
Contributions :
- source : une requête contenant Bénévoles.B_Code, Bénévoles.B_Nom, triée
sur B_Nom
- nombre de colonnes : 2
- largeurs des colonnes : 0;8 cm
- colonne liée : 1
- valeur par défaut : =mindom("[B_Nom]";"[Bénévoles]")
Acces va automatiquement stocker l'index du bénévole choisi dans la liste
pour la contribution courante...
Et par défaut, tu auras le premier nom par ordre alpha affiché dans ta
liste...
Tout ce que je t'ai dit sur la gestion des valeurs par défaut précédemment
ne concerne pas tout à fait ce cas de figure...
Mais on peut en reparler lundi !
Bonne soirée et bon week-end !
Daniel
Comme ça, sans avoir le temps de beaucoup détailler, je dirais que ton problème pourrait être résolu facilement à l'aide d'un formulaire Contributions, basé sur une table du même nom (la tienne est presque OK), avec, pour renseigner le bénévole, une liste déroulante qui va piocher dans la table Bénévoles...
La correction la plus importante, c'est cette table Bénévoles : pourquoi 2 tables là où une seule suffit ? Exemple de structure : - B_Code : numéroAuto, clé - B_Nom : texte de xx caractères
La table Contributions : - C_Code : numéroAuto, Clé - C_Bénévole : Entier, indexé avec doublons - C_Montant : monétaire - C_Date : Date
L'idéal serait de définir en dur la relation Bénévoles.B_Code <-> Contributions.C_Bénévole, et d'appliquer l'intégrité référentielle, de manière à éviter les contributions sans bénévole...
Les caractéristiques de la liste déroulante C_Bénévole sur le formulaire Contributions : - source : une requête contenant Bénévoles.B_Code, Bénévoles.B_Nom, triée sur B_Nom - nombre de colonnes : 2 - largeurs des colonnes : 0;8 cm - colonne liée : 1 - valeur par défaut : =mindom("[B_Nom]";"[Bénévoles]")
Acces va automatiquement stocker l'index du bénévole choisi dans la liste pour la contribution courante... Et par défaut, tu auras le premier nom par ordre alpha affiché dans ta liste...
Tout ce que je t'ai dit sur la gestion des valeurs par défaut précédemment ne concerne pas tout à fait ce cas de figure... Mais on peut en reparler lundi ! Bonne soirée et bon week-end ! Daniel
J.Pierre
Re-bonjour Daniel,
en re-vérifiant la syntaxe de rechdom, je me suis aperçu d'une erreur. La syntaxe corrigée que j'ai actuellement est la suivante :
Je n'ai plus le code d'erreur, mais pas contre, il n'y a aucune valeur dans le champ Code bénévole de la table [Contribution].
Je progresse tout de même.
Merci beaucoup!
Jean-Pierre
"Daniel" a écrit :
Salut Jean-Pierre,
C'est vrai qu'Access fournit cette possibilité, mais honnêtement, je lui ai toujours préféré de beaucoup une autre solution : - une table des valeurs par défaut, contenant un seul enregistrement, et un champ pour pratiquement chaque liste déroulante de l'application; - un formulaire des valeurs par défaut, chacune choisie dans une liste déroulante basée sur la table concernée... - dans chaque liste déroulante de l'application où une valeur par défaut est attendue, on la renseigne avec un simple et rapide RechDom (exemple : =rechdom("[D_Ville]";"[Valeurs_Défaut]")...).
C'est donc l'utilisateur qui choisira quelles valeurs par défaut il souhaite avoir à la création d'un enregistrement... L'avantage est que bien sûr, tu pourras appliquer l'intégrité référentielle les yeux fermés, puisque le choix dans la liste sera obligatoire...
Exemple classique : une adresse complète... Si tes adresses sont presque toutes situées à Paris, tu as intérêt à ce que la valeur par défaut soit Paris. Mais si d'un coup tu transposes ton application à Marseille, il ne faut pas que tu sois obligé d'intervenir sur la structure de ta base pour modifier la valeur par défaut. Il suffira d'aller modifier la valeur dans le formulaire des valeurs par défaut.
L'exemple de la ville peut sembler tiré par les cheveux, mais si on passe en revue toutes les valeurs par défaut dont on a besoin dans une application, l'utilité d'une telle table n'est plus à démontrer, sauf à se passer des valeurs par défaut...
Voilà, j'espère avoir pu t'aider A+ Daniel
Re-bonjour Daniel,
en re-vérifiant la syntaxe de rechdom, je me suis aperçu d'une erreur. La
syntaxe corrigée que j'ai actuellement est la suivante :
Je n'ai plus le code d'erreur, mais pas contre, il n'y a aucune valeur dans
le champ Code bénévole de la table [Contribution].
Je progresse tout de même.
Merci beaucoup!
Jean-Pierre
"Daniel" a écrit :
Salut Jean-Pierre,
C'est vrai qu'Access fournit cette possibilité, mais honnêtement, je lui ai
toujours préféré de beaucoup une autre solution :
- une table des valeurs par défaut, contenant un seul enregistrement, et un
champ pour pratiquement chaque liste déroulante de l'application;
- un formulaire des valeurs par défaut, chacune choisie dans une liste
déroulante basée sur la table concernée...
- dans chaque liste déroulante de l'application où une valeur par défaut est
attendue, on la renseigne avec un simple et rapide RechDom (exemple :
=rechdom("[D_Ville]";"[Valeurs_Défaut]")...).
C'est donc l'utilisateur qui choisira quelles valeurs par défaut il souhaite
avoir à la création d'un enregistrement...
L'avantage est que bien sûr, tu pourras appliquer l'intégrité référentielle
les yeux fermés, puisque le choix dans la liste sera obligatoire...
Exemple classique : une adresse complète... Si tes adresses sont presque
toutes situées à Paris, tu as intérêt à ce que la valeur par défaut soit
Paris. Mais si d'un coup tu transposes ton application à Marseille, il ne
faut pas que tu sois obligé d'intervenir sur la structure de ta base pour
modifier la valeur par défaut. Il suffira d'aller modifier la valeur dans le
formulaire des valeurs par défaut.
L'exemple de la ville peut sembler tiré par les cheveux, mais si on passe en
revue toutes les valeurs par défaut dont on a besoin dans une application,
l'utilité d'une telle table n'est plus à démontrer, sauf à se passer des
valeurs par défaut...
Je n'ai plus le code d'erreur, mais pas contre, il n'y a aucune valeur dans le champ Code bénévole de la table [Contribution].
Je progresse tout de même.
Merci beaucoup!
Jean-Pierre
"Daniel" a écrit :
Salut Jean-Pierre,
C'est vrai qu'Access fournit cette possibilité, mais honnêtement, je lui ai toujours préféré de beaucoup une autre solution : - une table des valeurs par défaut, contenant un seul enregistrement, et un champ pour pratiquement chaque liste déroulante de l'application; - un formulaire des valeurs par défaut, chacune choisie dans une liste déroulante basée sur la table concernée... - dans chaque liste déroulante de l'application où une valeur par défaut est attendue, on la renseigne avec un simple et rapide RechDom (exemple : =rechdom("[D_Ville]";"[Valeurs_Défaut]")...).
C'est donc l'utilisateur qui choisira quelles valeurs par défaut il souhaite avoir à la création d'un enregistrement... L'avantage est que bien sûr, tu pourras appliquer l'intégrité référentielle les yeux fermés, puisque le choix dans la liste sera obligatoire...
Exemple classique : une adresse complète... Si tes adresses sont presque toutes situées à Paris, tu as intérêt à ce que la valeur par défaut soit Paris. Mais si d'un coup tu transposes ton application à Marseille, il ne faut pas que tu sois obligé d'intervenir sur la structure de ta base pour modifier la valeur par défaut. Il suffira d'aller modifier la valeur dans le formulaire des valeurs par défaut.
L'exemple de la ville peut sembler tiré par les cheveux, mais si on passe en revue toutes les valeurs par défaut dont on a besoin dans une application, l'utilité d'une telle table n'est plus à démontrer, sauf à se passer des valeurs par défaut...
Voilà, j'espère avoir pu t'aider A+ Daniel
Daniel
Normal, ton message d'erreur : il faudrait réunir tes 2 tables Bénévoles et Paramètre Bénévole en 1 seule... : y en a une en trop... Voir mon post précédent... A+ Daniel
Normal, ton message d'erreur : il faudrait réunir tes 2 tables Bénévoles et
Paramètre Bénévole en 1 seule... : y en a une en trop...
Voir mon post précédent...
A+ Daniel
Normal, ton message d'erreur : il faudrait réunir tes 2 tables Bénévoles et Paramètre Bénévole en 1 seule... : y en a une en trop... Voir mon post précédent... A+ Daniel
