Il y a donc bien une 3eme table "chantier" (id_chatier etc...) mais c'est
juste pour aider à comprendre.
affectation.cout_sal doit être le produit de salarie.cout_quotidien_sal et
affectation.coeff.
Je sais que normalement on ne mémorise pas de valeurs calculées dans une
table mais dans ce cas j'y suis contraint...
Bref j'ai un formulaire qui me sert à remplir les 4 premiers champs de
"affectation" qui est organisé comme suit :
combo de sélection du salarié (listesal) | combo de sélection du chantier |
champ "date" | champ "coeff" | champ "cout_sal"
le champ "cout_sal" me calcule déjà correctement ce que je veux y afficher
(=[listesal].[Column(2)]*coeff) mais puisque dans la source de controle de
mon champ j'ai "=[listesal].[Column(2)]*coeff" je ne peux pas lui dire de
mémoriser la valeur ainsi calculée à la rubrique "affectation.cout_sal".
Donc en résumé, je ne sais pas comment permettre à un champ d'effectuer
dynamiquement un calcul en fonction de la valeur d'autres éléments du
formulaire mais en même temps spécifier que cette valeur doit être insérée
dans la table sur laquelle est basé mon formulaire...
Ouf. J'espère avoir été claire et merci par avance de l'aide que vous
voudrez bien m'apporter.
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
3stone
Salut,
"Errabé" [...] | Donc en résumé, je ne sais pas comment permettre à un champ d'effectuer | dynamiquement un calcul en fonction de la valeur d'autres éléments du | formulaire mais en même temps spécifier que cette valeur doit être insérée | dans la table sur laquelle est basé mon formulaire...
comme tu dis, cela se fait pas...
mais, sur "après mise à jour" du formulaire, tu mettre qque chose comme:
"Errabé"
[...]
| Donc en résumé, je ne sais pas comment permettre à un champ d'effectuer
| dynamiquement un calcul en fonction de la valeur d'autres éléments du
| formulaire mais en même temps spécifier que cette valeur doit être insérée
| dans la table sur laquelle est basé mon formulaire...
comme tu dis, cela se fait pas...
mais, sur "après mise à jour" du formulaire, tu mettre qque chose comme:
"Errabé" [...] | Donc en résumé, je ne sais pas comment permettre à un champ d'effectuer | dynamiquement un calcul en fonction de la valeur d'autres éléments du | formulaire mais en même temps spécifier que cette valeur doit être insérée | dans la table sur laquelle est basé mon formulaire...
comme tu dis, cela se fait pas...
mais, sur "après mise à jour" du formulaire, tu mettre qque chose comme:
C'est à dire qu'il est impossible de calculer la valeur d'un champ ayant une rubrique pour source de controle en fonction d'autres champs du formulaire ?
Champ A vaut 10, champ B vaut 10, si le champ C alimente la rubrique C d'une table, est-ce à dire qu'on ne peut pas spécifier à C de faire la calcul (champ A * champ B) pour l'insérer dans la table ? Car c'est cela que je veux faire... Je veux faire en sorte que par défaut mon champ C affiche la valeur de (champ A * champ B) pour ne pas que l'utilisateur ait à saisir la valeur...
Et sinon j'ai bien mis en "après maj" de mon formulaire : [cout]=[listesal].[Column(2)]*coeff et celà ne marche pas. Si je le mets ailleurs que après MAJ du formulaire, j'ai un message d'erreur qui me dit que la macro n'a pas été trouvée...
Voilà, je reformule donc je veux que C fasse le produit de la valeur de 2 autres champs pour ne pas que l'utilisateur ait à saisir le produit lui même...
Merci beaucoup d'avance à ceux qui me répondront. Rob
"3stone" a écrit dans le message de news:
Salut,
"Errabé" [...] | Donc en résumé, je ne sais pas comment permettre à un champ d'effectuer | dynamiquement un calcul en fonction de la valeur d'autres éléments du | formulaire mais en même temps spécifier que cette valeur doit être insérée
| dans la table sur laquelle est basé mon formulaire...
comme tu dis, cela se fait pas...
mais, sur "après mise à jour" du formulaire, tu mettre qque chose comme:
C'est à dire qu'il est impossible de calculer la valeur d'un champ ayant une
rubrique pour source de controle en fonction d'autres champs du formulaire ?
Champ A vaut 10, champ B vaut 10, si le champ C alimente la rubrique C d'une
table, est-ce à dire qu'on ne peut pas spécifier à C de faire la calcul
(champ A * champ B) pour l'insérer dans la table ? Car c'est cela que je
veux faire... Je veux faire en sorte que par défaut mon champ C affiche la
valeur de (champ A * champ B) pour ne pas que l'utilisateur ait à saisir la
valeur...
Et sinon j'ai bien mis en "après maj" de mon formulaire :
[cout]=[listesal].[Column(2)]*coeff et celà ne marche pas. Si je le mets
ailleurs que après MAJ du formulaire, j'ai un message d'erreur qui me dit
que la macro n'a pas été trouvée...
Voilà, je reformule donc je veux que C fasse le produit de la valeur de 2
autres champs pour ne pas que l'utilisateur ait à saisir le produit lui
même...
Merci beaucoup d'avance à ceux qui me répondront.
Rob
"3stone" <3stone_@_skynet_be> a écrit dans le message de news:
O1A3CZUDGHA.740@TK2MSFTNGP12.phx.gbl...
Salut,
"Errabé"
[...]
| Donc en résumé, je ne sais pas comment permettre à un champ d'effectuer
| dynamiquement un calcul en fonction de la valeur d'autres éléments du
| formulaire mais en même temps spécifier que cette valeur doit être
insérée
| dans la table sur laquelle est basé mon formulaire...
comme tu dis, cela se fait pas...
mais, sur "après mise à jour" du formulaire, tu mettre qque chose comme:
C'est à dire qu'il est impossible de calculer la valeur d'un champ ayant une rubrique pour source de controle en fonction d'autres champs du formulaire ?
Champ A vaut 10, champ B vaut 10, si le champ C alimente la rubrique C d'une table, est-ce à dire qu'on ne peut pas spécifier à C de faire la calcul (champ A * champ B) pour l'insérer dans la table ? Car c'est cela que je veux faire... Je veux faire en sorte que par défaut mon champ C affiche la valeur de (champ A * champ B) pour ne pas que l'utilisateur ait à saisir la valeur...
Et sinon j'ai bien mis en "après maj" de mon formulaire : [cout]=[listesal].[Column(2)]*coeff et celà ne marche pas. Si je le mets ailleurs que après MAJ du formulaire, j'ai un message d'erreur qui me dit que la macro n'a pas été trouvée...
Voilà, je reformule donc je veux que C fasse le produit de la valeur de 2 autres champs pour ne pas que l'utilisateur ait à saisir le produit lui même...
Merci beaucoup d'avance à ceux qui me répondront. Rob
"3stone" a écrit dans le message de news:
Salut,
"Errabé" [...] | Donc en résumé, je ne sais pas comment permettre à un champ d'effectuer | dynamiquement un calcul en fonction de la valeur d'autres éléments du | formulaire mais en même temps spécifier que cette valeur doit être insérée
| dans la table sur laquelle est basé mon formulaire...
comme tu dis, cela se fait pas...
mais, sur "après mise à jour" du formulaire, tu mettre qque chose comme:
"Errabé" | C'est à dire qu'il est impossible de calculer la valeur d'un champ ayant une | rubrique pour source de controle en fonction d'autres champs du formulaire ?
une "rubrique" pour source de controle ?
tu peux très simplement comme source d'une zone de texte sur un formulaire:
= ChampA * ChampB
c'est de sauver ce résultat dans une table qui ne se fait pas !!
| Champ A vaut 10, champ B vaut 10, si le champ C alimente la rubrique C d'une | table, est-ce à dire qu'on ne peut pas spécifier à C de faire la calcul | (champ A * champ B) pour l'insérer dans la table ? Car c'est cela que je | veux faire... Je veux faire en sorte que par défaut mon champ C affiche la | valeur de (champ A * champ B) pour ne pas que l'utilisateur ait à saisir la | valeur...
l'utilisateur n'a pas à sasir de valeur (si tu parle de la valeur de C )
mais le sauver dans une table est inutile et redondant... Interesse-toi plutôt aux requêtes dans lesquelles tu pourras faire calculer la valeur de C en étant certain de sa réalité !
| Et sinon j'ai bien mis en "après maj" de mon formulaire : | [cout]=[listesal].[Column(2)]*coeff et celà ne marche pas. Si je le mets | ailleurs que après MAJ du formulaire, j'ai un message d'erreur qui me dit | que la macro n'a pas été trouvée...
[cout]= val([listesal].column(2)) * coeff
devrait le faire... pour renseigner la 3e colonne ! Mais je répète : on ne fait pas cela !!
| Voilà, je reformule donc je veux que C fasse le produit de la valeur de 2 | autres champs pour ne pas que l'utilisateur ait à saisir le produit lui | même...
tu utilise une machine à écrire, d'habitude ? ;-)) le mieux est donc de demander comment on fait, au lieu de suivre une idée fixe ( et fausse de surcroit )
"Errabé"
| C'est à dire qu'il est impossible de calculer la valeur d'un champ ayant une
| rubrique pour source de controle en fonction d'autres champs du formulaire ?
une "rubrique" pour source de controle ?
tu peux très simplement comme source d'une zone de texte sur un formulaire:
= ChampA * ChampB
c'est de sauver ce résultat dans une table qui ne se fait pas !!
| Champ A vaut 10, champ B vaut 10, si le champ C alimente la rubrique C d'une
| table, est-ce à dire qu'on ne peut pas spécifier à C de faire la calcul
| (champ A * champ B) pour l'insérer dans la table ? Car c'est cela que je
| veux faire... Je veux faire en sorte que par défaut mon champ C affiche la
| valeur de (champ A * champ B) pour ne pas que l'utilisateur ait à saisir la
| valeur...
l'utilisateur n'a pas à sasir de valeur (si tu parle de la valeur de C )
mais le sauver dans une table est inutile et redondant...
Interesse-toi plutôt aux requêtes dans lesquelles tu pourras faire
calculer la valeur de C en étant certain de sa réalité !
| Et sinon j'ai bien mis en "après maj" de mon formulaire :
| [cout]=[listesal].[Column(2)]*coeff et celà ne marche pas. Si je le mets
| ailleurs que après MAJ du formulaire, j'ai un message d'erreur qui me dit
| que la macro n'a pas été trouvée...
[cout]= val([listesal].column(2)) * coeff
devrait le faire... pour renseigner la 3e colonne !
Mais je répète : on ne fait pas cela !!
| Voilà, je reformule donc je veux que C fasse le produit de la valeur de 2
| autres champs pour ne pas que l'utilisateur ait à saisir le produit lui
| même...
tu utilise une machine à écrire, d'habitude ? ;-))
le mieux est donc de demander comment on fait, au lieu de suivre
une idée fixe ( et fausse de surcroit )
"Errabé" | C'est à dire qu'il est impossible de calculer la valeur d'un champ ayant une | rubrique pour source de controle en fonction d'autres champs du formulaire ?
une "rubrique" pour source de controle ?
tu peux très simplement comme source d'une zone de texte sur un formulaire:
= ChampA * ChampB
c'est de sauver ce résultat dans une table qui ne se fait pas !!
| Champ A vaut 10, champ B vaut 10, si le champ C alimente la rubrique C d'une | table, est-ce à dire qu'on ne peut pas spécifier à C de faire la calcul | (champ A * champ B) pour l'insérer dans la table ? Car c'est cela que je | veux faire... Je veux faire en sorte que par défaut mon champ C affiche la | valeur de (champ A * champ B) pour ne pas que l'utilisateur ait à saisir la | valeur...
l'utilisateur n'a pas à sasir de valeur (si tu parle de la valeur de C )
mais le sauver dans une table est inutile et redondant... Interesse-toi plutôt aux requêtes dans lesquelles tu pourras faire calculer la valeur de C en étant certain de sa réalité !
| Et sinon j'ai bien mis en "après maj" de mon formulaire : | [cout]=[listesal].[Column(2)]*coeff et celà ne marche pas. Si je le mets | ailleurs que après MAJ du formulaire, j'ai un message d'erreur qui me dit | que la macro n'a pas été trouvée...
[cout]= val([listesal].column(2)) * coeff
devrait le faire... pour renseigner la 3e colonne ! Mais je répète : on ne fait pas cela !!
| Voilà, je reformule donc je veux que C fasse le produit de la valeur de 2 | autres champs pour ne pas que l'utilisateur ait à saisir le produit lui | même...
tu utilise une machine à écrire, d'habitude ? ;-)) le mieux est donc de demander comment on fait, au lieu de suivre une idée fixe ( et fausse de surcroit )
Alors je reprends ma machine à écrire :) et j'explique la raison pour laquelle je souhaite mémoriser un champ calculé...
J'ai ma table 'salarié' Table salarie ------------------- id_sal nom_sal cout_quotidien_sal
et ma table d'association 'affecter' qui fait la liaison entre les tables 'salarié' et 'chantier' Table affectation ------------------- id_sal id_chantier date_affectation coeff
Je calcule aujourd'hui le cout quotidien de chaque salarié avec des requêtes qui vont chercher les bonnes infos au bon entroit et tout marche bien comme ça. Seulement le 'cout_quotidien_sal' évolue et si je change la valeur de 'cout_quotidien_sal' pour un salarié donné, les états d'historique seront faussés. Je m'explique. Si j'alimente ma table salarie : id_sal | nom_sal | cout_quotidien_sal 1 | Robson | 250
Si j'alimente ma table 'affectation' id_sal | id_chantier | date_affectation | coeff 1 | 1 | 31/12/2005 | 1
Je vais pouvoir calculer que pour le 31/12/2005 mon salarié m'a couté 250 * 1 = 250 euros (cout_quotidien_sal * coeff) Maintenant je souhaite changer 'cout_quotidien_sal' pour le salarié 'Robson' et le passer à 300.
Donc j'ai 1 | Robson | 250 et je saisis une nouvelle ligne dans 'affecter' 1 | 1 | 01/01/2006 | 1
le 'truc' c'est que je veux pouvoir savoir combien m'a couté le salarié le 31/12/2005 car si je change la valeur de 'cout_quotidien_sal' ma requete va me retourner que le 31/12/2005 Robson m'a couté 300 euros, ce qui est faux...
Alors je me suis dit que le mieux c'était de mémoriser 'en dur' ce que me coute chaque jour un salarié pour ne pas avoir ce type de problème et changer librement le montant de 'cout_quotidien_sal'... ce qui explique le champ 'cout_sal' que je voulais rajouter dans la table 'affectation'...
Merci de ton aide 3stone, c'est bien sympa de t'intéresser à ce satané problème que je n'arrive pas à résoudre tout seul...
Rob
"3stone" a écrit dans le message de news:
Salut,
"Errabé" | C'est à dire qu'il est impossible de calculer la valeur d'un champ ayant une
| rubrique pour source de controle en fonction d'autres champs du formulaire ?
une "rubrique" pour source de controle ?
tu peux très simplement comme source d'une zone de texte sur un formulaire:
= ChampA * ChampB
c'est de sauver ce résultat dans une table qui ne se fait pas !!
| Champ A vaut 10, champ B vaut 10, si le champ C alimente la rubrique C d'une
| table, est-ce à dire qu'on ne peut pas spécifier à C de faire la calcul | (champ A * champ B) pour l'insérer dans la table ? Car c'est cela que je | veux faire... Je veux faire en sorte que par défaut mon champ C affiche la
| valeur de (champ A * champ B) pour ne pas que l'utilisateur ait à saisir la
| valeur...
l'utilisateur n'a pas à sasir de valeur (si tu parle de la valeur de C )
mais le sauver dans une table est inutile et redondant... Interesse-toi plutôt aux requêtes dans lesquelles tu pourras faire calculer la valeur de C en étant certain de sa réalité !
| Et sinon j'ai bien mis en "après maj" de mon formulaire : | [cout]=[listesal].[Column(2)]*coeff et celà ne marche pas. Si je le mets | ailleurs que après MAJ du formulaire, j'ai un message d'erreur qui me dit
| que la macro n'a pas été trouvée...
[cout]= val([listesal].column(2)) * coeff
devrait le faire... pour renseigner la 3e colonne ! Mais je répète : on ne fait pas cela !!
| Voilà, je reformule donc je veux que C fasse le produit de la valeur de 2
| autres champs pour ne pas que l'utilisateur ait à saisir le produit lui | même...
tu utilise une machine à écrire, d'habitude ? ;-)) le mieux est donc de demander comment on fait, au lieu de suivre une idée fixe ( et fausse de surcroit )
Alors je reprends ma machine à écrire :) et j'explique la raison pour
laquelle je souhaite mémoriser un champ calculé...
J'ai ma table 'salarié'
Table salarie
-------------------
id_sal
nom_sal
cout_quotidien_sal
et ma table d'association 'affecter' qui fait la liaison entre les tables
'salarié' et 'chantier'
Table affectation
-------------------
id_sal
id_chantier
date_affectation
coeff
Je calcule aujourd'hui le cout quotidien de chaque salarié avec des requêtes
qui vont chercher les bonnes infos au bon entroit et tout marche bien comme
ça. Seulement le 'cout_quotidien_sal' évolue et si je change la valeur de
'cout_quotidien_sal' pour un salarié donné, les états d'historique seront
faussés. Je m'explique.
Si j'alimente ma table salarie :
id_sal | nom_sal | cout_quotidien_sal
1 | Robson | 250
Si j'alimente ma table 'affectation'
id_sal | id_chantier | date_affectation | coeff
1 | 1 | 31/12/2005 | 1
Je vais pouvoir calculer que pour le 31/12/2005 mon salarié m'a couté 250 *
1 = 250 euros (cout_quotidien_sal * coeff)
Maintenant je souhaite changer 'cout_quotidien_sal' pour le salarié 'Robson'
et le passer à 300.
Donc j'ai
1 | Robson | 250
et je saisis une nouvelle ligne dans 'affecter'
1 | 1 | 01/01/2006 | 1
le 'truc' c'est que je veux pouvoir savoir combien m'a couté le salarié le
31/12/2005 car si je change la valeur de 'cout_quotidien_sal' ma requete va
me retourner que le 31/12/2005 Robson m'a couté 300 euros, ce qui est
faux...
Alors je me suis dit que le mieux c'était de mémoriser 'en dur' ce que me
coute chaque jour un salarié pour ne pas avoir ce type de problème et
changer librement le montant de 'cout_quotidien_sal'... ce qui explique le
champ 'cout_sal' que je voulais rajouter dans la table 'affectation'...
Merci de ton aide 3stone, c'est bien sympa de t'intéresser à ce satané
problème que je n'arrive pas à résoudre tout seul...
Rob
"3stone" <3stone_@_skynet_be> a écrit dans le message de news:
OUYDjaxDGHA.3064@TK2MSFTNGP10.phx.gbl...
Salut,
"Errabé"
| C'est à dire qu'il est impossible de calculer la valeur d'un champ ayant
une
| rubrique pour source de controle en fonction d'autres champs du
formulaire ?
une "rubrique" pour source de controle ?
tu peux très simplement comme source d'une zone de texte sur un
formulaire:
= ChampA * ChampB
c'est de sauver ce résultat dans une table qui ne se fait pas !!
| Champ A vaut 10, champ B vaut 10, si le champ C alimente la rubrique C
d'une
| table, est-ce à dire qu'on ne peut pas spécifier à C de faire la calcul
| (champ A * champ B) pour l'insérer dans la table ? Car c'est cela que je
| veux faire... Je veux faire en sorte que par défaut mon champ C affiche
la
| valeur de (champ A * champ B) pour ne pas que l'utilisateur ait à saisir
la
| valeur...
l'utilisateur n'a pas à sasir de valeur (si tu parle de la valeur de C )
mais le sauver dans une table est inutile et redondant...
Interesse-toi plutôt aux requêtes dans lesquelles tu pourras faire
calculer la valeur de C en étant certain de sa réalité !
| Et sinon j'ai bien mis en "après maj" de mon formulaire :
| [cout]=[listesal].[Column(2)]*coeff et celà ne marche pas. Si je le mets
| ailleurs que après MAJ du formulaire, j'ai un message d'erreur qui me
dit
| que la macro n'a pas été trouvée...
[cout]= val([listesal].column(2)) * coeff
devrait le faire... pour renseigner la 3e colonne !
Mais je répète : on ne fait pas cela !!
| Voilà, je reformule donc je veux que C fasse le produit de la valeur de
2
| autres champs pour ne pas que l'utilisateur ait à saisir le produit lui
| même...
tu utilise une machine à écrire, d'habitude ? ;-))
le mieux est donc de demander comment on fait, au lieu de suivre
une idée fixe ( et fausse de surcroit )
Alors je reprends ma machine à écrire :) et j'explique la raison pour laquelle je souhaite mémoriser un champ calculé...
J'ai ma table 'salarié' Table salarie ------------------- id_sal nom_sal cout_quotidien_sal
et ma table d'association 'affecter' qui fait la liaison entre les tables 'salarié' et 'chantier' Table affectation ------------------- id_sal id_chantier date_affectation coeff
Je calcule aujourd'hui le cout quotidien de chaque salarié avec des requêtes qui vont chercher les bonnes infos au bon entroit et tout marche bien comme ça. Seulement le 'cout_quotidien_sal' évolue et si je change la valeur de 'cout_quotidien_sal' pour un salarié donné, les états d'historique seront faussés. Je m'explique. Si j'alimente ma table salarie : id_sal | nom_sal | cout_quotidien_sal 1 | Robson | 250
Si j'alimente ma table 'affectation' id_sal | id_chantier | date_affectation | coeff 1 | 1 | 31/12/2005 | 1
Je vais pouvoir calculer que pour le 31/12/2005 mon salarié m'a couté 250 * 1 = 250 euros (cout_quotidien_sal * coeff) Maintenant je souhaite changer 'cout_quotidien_sal' pour le salarié 'Robson' et le passer à 300.
Donc j'ai 1 | Robson | 250 et je saisis une nouvelle ligne dans 'affecter' 1 | 1 | 01/01/2006 | 1
le 'truc' c'est que je veux pouvoir savoir combien m'a couté le salarié le 31/12/2005 car si je change la valeur de 'cout_quotidien_sal' ma requete va me retourner que le 31/12/2005 Robson m'a couté 300 euros, ce qui est faux...
Alors je me suis dit que le mieux c'était de mémoriser 'en dur' ce que me coute chaque jour un salarié pour ne pas avoir ce type de problème et changer librement le montant de 'cout_quotidien_sal'... ce qui explique le champ 'cout_sal' que je voulais rajouter dans la table 'affectation'...
Merci de ton aide 3stone, c'est bien sympa de t'intéresser à ce satané problème que je n'arrive pas à résoudre tout seul...
Rob
"3stone" a écrit dans le message de news:
Salut,
"Errabé" | C'est à dire qu'il est impossible de calculer la valeur d'un champ ayant une
| rubrique pour source de controle en fonction d'autres champs du formulaire ?
une "rubrique" pour source de controle ?
tu peux très simplement comme source d'une zone de texte sur un formulaire:
= ChampA * ChampB
c'est de sauver ce résultat dans une table qui ne se fait pas !!
| Champ A vaut 10, champ B vaut 10, si le champ C alimente la rubrique C d'une
| table, est-ce à dire qu'on ne peut pas spécifier à C de faire la calcul | (champ A * champ B) pour l'insérer dans la table ? Car c'est cela que je | veux faire... Je veux faire en sorte que par défaut mon champ C affiche la
| valeur de (champ A * champ B) pour ne pas que l'utilisateur ait à saisir la
| valeur...
l'utilisateur n'a pas à sasir de valeur (si tu parle de la valeur de C )
mais le sauver dans une table est inutile et redondant... Interesse-toi plutôt aux requêtes dans lesquelles tu pourras faire calculer la valeur de C en étant certain de sa réalité !
| Et sinon j'ai bien mis en "après maj" de mon formulaire : | [cout]=[listesal].[Column(2)]*coeff et celà ne marche pas. Si je le mets | ailleurs que après MAJ du formulaire, j'ai un message d'erreur qui me dit
| que la macro n'a pas été trouvée...
[cout]= val([listesal].column(2)) * coeff
devrait le faire... pour renseigner la 3e colonne ! Mais je répète : on ne fait pas cela !!
| Voilà, je reformule donc je veux que C fasse le produit de la valeur de 2
| autres champs pour ne pas que l'utilisateur ait à saisir le produit lui | même...
tu utilise une machine à écrire, d'habitude ? ;-)) le mieux est donc de demander comment on fait, au lieu de suivre une idée fixe ( et fausse de surcroit )
"Errabé" [...] | Alors je me suis dit que le mieux c'était de mémoriser 'en dur' ce que me | coute chaque jour un salarié pour ne pas avoir ce type de problème et | changer librement le montant de 'cout_quotidien_sal'... ce qui explique le | champ 'cout_sal' que je voulais rajouter dans la table 'affectation'...
mémoriser les dates de modifications du salaire permet de retrouver le salaire à un instant T
| Merci de ton aide 3stone, c'est bien sympa de t'intéresser à ce satané | problème que je n'arrive pas à résoudre tout seul...
je t'ai malgré tout donné la solution dans le message précédent !
"Errabé"
[...]
| Alors je me suis dit que le mieux c'était de mémoriser 'en dur' ce que me
| coute chaque jour un salarié pour ne pas avoir ce type de problème et
| changer librement le montant de 'cout_quotidien_sal'... ce qui explique le
| champ 'cout_sal' que je voulais rajouter dans la table 'affectation'...
mémoriser les dates de modifications du salaire permet de retrouver
le salaire à un instant T
| Merci de ton aide 3stone, c'est bien sympa de t'intéresser à ce satané
| problème que je n'arrive pas à résoudre tout seul...
je t'ai malgré tout donné la solution dans le message précédent !
"Errabé" [...] | Alors je me suis dit que le mieux c'était de mémoriser 'en dur' ce que me | coute chaque jour un salarié pour ne pas avoir ce type de problème et | changer librement le montant de 'cout_quotidien_sal'... ce qui explique le | champ 'cout_sal' que je voulais rajouter dans la table 'affectation'...
mémoriser les dates de modifications du salaire permet de retrouver le salaire à un instant T
| Merci de ton aide 3stone, c'est bien sympa de t'intéresser à ce satané | problème que je n'arrive pas à résoudre tout seul...
je t'ai malgré tout donné la solution dans le message précédent !
Oui 3stone, j'avais bien lu ta réponse mais je voulais me conformer à quelques chose tenant moins du bricolage mais effectivement étant donné le temps et les moyens dont je dispose, je vais parer au plus vite.
Pour info, la mise en place de ta solution sur le formulaire après maj ne marche que partiellement : je n'arrive pas à passer à l'enregistrement (ligne de saisie) suivant... En revanche j'ai placé ce code sur une combo dont je me sers sur le formulaire et là ça marche impec.
Donc, un grand merci à toi.
a+
Rob
Ps : heuuu c'est pas 3StoneS ? hem...
"3stone" a écrit dans le message de news: #
re,
"Errabé" [...] | Alors je me suis dit que le mieux c'était de mémoriser 'en dur' ce que me
| coute chaque jour un salarié pour ne pas avoir ce type de problème et | changer librement le montant de 'cout_quotidien_sal'... ce qui explique le
| champ 'cout_sal' que je voulais rajouter dans la table 'affectation'...
mémoriser les dates de modifications du salaire permet de retrouver le salaire à un instant T
| Merci de ton aide 3stone, c'est bien sympa de t'intéresser à ce satané | problème que je n'arrive pas à résoudre tout seul...
je t'ai malgré tout donné la solution dans le message précédent !
Oui 3stone, j'avais bien lu ta réponse mais je voulais me conformer à
quelques chose tenant moins du bricolage mais effectivement étant donné le
temps et les moyens dont je dispose, je vais parer au plus vite.
Pour info, la mise en place de ta solution sur le formulaire après maj ne
marche que partiellement : je n'arrive pas à passer à l'enregistrement
(ligne de saisie) suivant... En revanche j'ai placé ce code sur une combo
dont je me sers sur le formulaire et là ça marche impec.
Donc, un grand merci à toi.
a+
Rob
Ps : heuuu c'est pas 3StoneS ? hem...
"3stone" <3stone_@_skynet_be> a écrit dans le message de news:
#q8P5EyDGHA.4064@TK2MSFTNGP10.phx.gbl...
re,
"Errabé"
[...]
| Alors je me suis dit que le mieux c'était de mémoriser 'en dur' ce que
me
| coute chaque jour un salarié pour ne pas avoir ce type de problème et
| changer librement le montant de 'cout_quotidien_sal'... ce qui explique
le
| champ 'cout_sal' que je voulais rajouter dans la table 'affectation'...
mémoriser les dates de modifications du salaire permet de retrouver
le salaire à un instant T
| Merci de ton aide 3stone, c'est bien sympa de t'intéresser à ce satané
| problème que je n'arrive pas à résoudre tout seul...
je t'ai malgré tout donné la solution dans le message précédent !
Oui 3stone, j'avais bien lu ta réponse mais je voulais me conformer à quelques chose tenant moins du bricolage mais effectivement étant donné le temps et les moyens dont je dispose, je vais parer au plus vite.
Pour info, la mise en place de ta solution sur le formulaire après maj ne marche que partiellement : je n'arrive pas à passer à l'enregistrement (ligne de saisie) suivant... En revanche j'ai placé ce code sur une combo dont je me sers sur le formulaire et là ça marche impec.
Donc, un grand merci à toi.
a+
Rob
Ps : heuuu c'est pas 3StoneS ? hem...
"3stone" a écrit dans le message de news: #
re,
"Errabé" [...] | Alors je me suis dit que le mieux c'était de mémoriser 'en dur' ce que me
| coute chaque jour un salarié pour ne pas avoir ce type de problème et | changer librement le montant de 'cout_quotidien_sal'... ce qui explique le
| champ 'cout_sal' que je voulais rajouter dans la table 'affectation'...
mémoriser les dates de modifications du salaire permet de retrouver le salaire à un instant T
| Merci de ton aide 3stone, c'est bien sympa de t'intéresser à ce satané | problème que je n'arrive pas à résoudre tout seul...
je t'ai malgré tout donné la solution dans le message précédent !
- 3stone est très singulier - 3stone est invariable - 3stone est une unité monétaire donc ça ne prend pas de S comme sur les billets - 3 est à traduire littéralement par "triple" : comment tu écris triple buse toi ? avec un S ? (et ne me faites pas dire ce que je n'ai pas dit !!)
(rayer la mention inutile)
;-))) -- A+ Arnaud
Salut
"Errabé" <
Ps : heuuu c'est pas 3StoneS ? hem...
- 3stone est très singulier
- 3stone est invariable
- 3stone est une unité monétaire donc ça ne prend pas de S comme sur les billets
- 3 est à traduire littéralement par "triple" : comment tu écris triple buse toi ? avec un S ? (et ne me faites pas dire ce que je
n'ai pas dit !!)
- 3stone est très singulier - 3stone est invariable - 3stone est une unité monétaire donc ça ne prend pas de S comme sur les billets - 3 est à traduire littéralement par "triple" : comment tu écris triple buse toi ? avec un S ? (et ne me faites pas dire ce que je n'ai pas dit !!)
(rayer la mention inutile)
;-))) -- A+ Arnaud
3stone
| - 3 est à traduire littéralement par "triple" : comment tu écris triple buse toi ? avec un S ? (et ne me faites pas dire ce que je | n'ai pas dit !!)
STOP !!!
Sinon je traverse l'hexagone pour venir te "le" bouffer !!!
| - 3 est à traduire littéralement par "triple" : comment tu écris triple buse toi ? avec un S ? (et
ne me faites pas dire ce que je
| n'ai pas dit !!)
STOP !!!
Sinon je traverse l'hexagone pour venir te "le" bouffer !!!
| - 3 est à traduire littéralement par "triple" : comment tu écris triple buse toi ? avec un S ? (et ne me faites pas dire ce que je | n'ai pas dit !!)
STOP !!!
Sinon je traverse l'hexagone pour venir te "le" bouffer !!!
