Discussion :

[DamKre]

Bonjour,

J'ai un nouveau problème, similaire à celui récemment posté, mais néanmoins différent.

Dans une base de gestion des élèves ( oui, toujours ^^ ), on encode le comportement.
Chaque élève dispose de 120 points. Chaque faute lui fait perdre des points.

Pour ce faire, on se rend dans sa fiche, et plus précisément dans le sous-formulaire d'encodage.

Voici, par exemple ( et en simplifié ) ce que cela donne pour l'élève :

Date	Prof	Fait	Points retirés
01/09/2017	Prof1	Bavardage	1
02/09/2017	Prof1	Bavardage	2
02/09/2017	Prof2	Mange en classe	1
03/09/2017	Directeur	Bagarre	10
...	...	...	...

Le but est d'avoir une alerte chaque fois que l'élève a perdu un multiple de 20 points ( cette valeur 20 peut changer ; elle est stockée dans une table paramètres ).

Sauf erreur de ma part, la fonction mod, lancée après insertion, renseignée dans cette discussion ne convient pas : si l'élève a perdu la somme de 39 points, qu'on lui en enlève ensuite 2, Mod =/= 0 et l'alerte 40 ( 2X20 ) ne se lancera donc pas.

Voyez-vous une solution à laquelle je n'aurais pas pensé ?

Merci de votre aide !

[ClaudeLELOUP]

Bonjour,

On pourrait par exemple ajouter une colonne à cette table (SeuilFranchi).
Lorsqu’une alerte est donnée, on stockerait dans SeuilFranchi de l’enregistrement déclencheur le seuil qui a été dépassé (dans ton exemple un multiple de 20).
À chaque nouvel enregistrement, on lance un processus qui calcule :
nz(dernier SeuilFranchi) ;0) + la valeur du paramètre – somme des pénalités.
Si le résultat >0, rien ne se passe.
Si le résultat <=0, on déclenche une alerte
et on mémorise (dernier SeuilFranchi) + la valeur du paramètre dans SeuilFranchi de l’enregistrement en question.

[tee_grandbois]

Bonjour,
une autre possibilité sans stocker de résultat : la somme des points retirés divisée par la valeur du paramètre donne un nombre dont la valeur entière (Int(X)) du calcul donne le nombre de fois que l'alerte est franchie :

Code :

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

1
2
3
 select Int(Sum([nb_points])/DFirst("valeurparam","tab_param","id_param=1")) AS SeuilAlerte
...
HAVING Int(Sum([nbre_points])/ DFirst("valeurparam","tab_param","id_param=1"))>1

[ClaudeLELOUP]

Bonjour Guy,

Mais comment sais-tu que l'alerte n'a pas déjà été donnée ? Il faut mémoriser quelque part le nombre d'alertes qui ont été lancées et si ce nbre est égal à celui que tu calcules, il ne faut rien faire.

[tee_grandbois]

Bonjour Guy,

Mais comment sais-tu que l'alerte n'a pas déjà été donnée ? Il faut mémoriser quelque part le nombre d'alertes qui ont été lancées et si ce nbre est égal à celui que tu calcules, il ne faut rien faire.

Bonsoir Claude,
tu as raison il faudrait au mois un champ de stockage de la dernière alerte, une date par exemple, qui pourrait de ce fait servir de filtre pour le calcul des pénalités.

Après réflexion, la solution que je propose n'est pas adaptée et ne fonctionne pas pour le cas de figure précité par DamKre (alerte à 39 points dont on ôte ensuite 2 points) car dans ce cas aussi les 2 points vont déclencher l'alerte à une date donnée mais le point supplémentaire ne sera pas répercuté sur la date la plus proche.
La solution de Claude semble être la mieux adaptée.

[DamKre]

Bonjour à tous les deux,
Merci d'avoir pris le temps de réfléchir à ce cas.

Avant de mettre en place un champ "seuil franchi", plusieurs réflexions quant à ce qui va se passer sur le terrain :

• Il peut arriver qu'on retire une sanction ( et donc, que l'élève récupère le(s) point(s) perdu(s) ). Et ce n'est pas forcément la dernière sanction qui est annulée. Ainsi, la sanction du 5/09 peut être annulée, mais on conserve les précédentes et les suivantes.
  
  --> le champ seuil franchi est-il toujours la solution ?
• Les élèves sont sanctionnés en cas de retard à l'école. Si je veux prévoir une alerte à chaque pallier de 5 retards ( 5 ou 7 ou 12, ... ), on multiplie alors les champs "seuil franchi" : [seuilfranchi_general], [seuilfranchi_retard], [seuilfranchi_violence]...
  
  --> est-il intéressant de multiplier ainsi les champs "seuil franchi" ?

Petite idée s'inspirant alors du seuil franchi proposé par Claude :

• La procédure de lancement ( ou non ) d'alerte se fait sur sortie du sous-formulaire d'encodage.
  --> Elle tient compte des points qui ont été récupérés.
• On regarde dans le champ [TableEleves]![ChampSeuilFranchi_Comportementgénéral] la valeur du dernier seuil et la valeur des points perdus.
  
  • Si la dernière alerte était "20" et qu'on a atteint ou dépassé 40, on lance l'alerte ;
  • Si la dernière alerte était "20" et qu'on atteinte pas 40, pas d'alerte ;
  • Si la dernière alerte était "40", que l'élève a récupéré des points et qu'on est descendu en-dessous de 40, pas d'alerte ;
  • Si la dernière alerte était "40", que l'élève a récupéré des points et qu'il en a reperdu ensuite, qu'on atteint ou dépasse à nouveau "40", pas d'alerte ( l'alerte 40 ayant déjà été lancée ).
    
    --> Que pensez-vous de ce principe ?
  
  
• Y a-t-il une autre solution que d'ajouter 5-6 champs "Seuil franchi" ( un par type d'alerte ) dans la table des élèves, déjà bien chargée en différents champs ( elle en a déjà plus de 60 et je suppose que le nombre de champs est limité ^^ ) ?

Que pensez-vous de toutes ces réflexions ?
Merci du temps que vous allez passer à ce cas ;-)
Bon dimanche !