Discussion :

[voyager75]

Bonjour,

Je n'arrive pas à trouver la solution donc je m'adresse à vous.
Je souhaite tracabiliser les changements de rémunération.
Je m'explique:

2 tables:
personnel avec un champs salaire et tmp.
historique_salaire avec un champs montant et raison.

1 déclencheur sur table personnel (after update):

Code :

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

1
2
3
IF NEW.salaire <> OLD.salaire THEN
  INSERT INTO historique_salaire (montant) VALUES(NEW.salaire);
ENDIF;

Jusque la ça va.

Mais dans différents scripts php, il y a des requêtes du type:

Code :

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

UPDATE personnel SET salaire=XXX WHERE id=22;

Je vais modifier ces requêtes, une par une pour:

Code :

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

UPDATE personnel SET salaire=XXX, tmp="Raison du changement" WHERE id=22;

Et donc mettre la raison du changement dans le champ raison de la table historique en modifiant le trigger.

Jusque la ça va bis.

Par contre, je souhaiterais, une fois fait, vider le champ tmp de la table personnel.
Pour ne pas qu'une requête non modifiée, déclenche la copie du champ tmp vers raison.

J'ai essayé avec trigger avant, après, sur les 2 tables, mais je ne m'en sors pas.

Avez vous une idée?

Merci

[punkoff]

bonjour,


en faisant : new.tmp =''; ca ne marche pas ?

[MacFly58]

Bonsoir,

La présence de la colonne 'Raison' dans la table Personnel me semble étrange. Cette colonne ne devrait se trouver que dans la table historique_salaire en toute logique.

Peut être avez-vous un problème de conception dans cette bdd, car théoriquement votre problème ne devrait pas exister.

Si vous souhaitez approfondir cette réflexion, il faudrait également vérifier quelles sont les colonnes qui gèrent les dates entre lesquelles les salaires sont valides. A priori, 3 colonnes sont nécessaires pour gérer ce cas.

[voyager75]

en faisant : new.tmp =''; ca ne marche pas ?

Je voudrais bien que ce soit aussi simple mais impossible de modifier NEW.tmp dans trigger AFTER.
Et si je veux le faire dans trigger historique, il mord la queue du trigger personnel.
J'ai peur que ce que je veux soit impossible ?!?!?!

Peut être avez-vous un problème de conception dans cette bdd, car théoriquement votre problème ne devrait pas exister.

Tout à fait d'accord et c'est le moins qu'on puisse dire.

Simplement j'hérite du sal boulot.
Un simple exemple qui veut tout dire:
Un membre du personnel est parfois identifié par son id, parfois par son nom (en fait concaténation nom_prénom).
Du coup, lorsque quelqu'un divorce ou se mari....
Heureusement qu'il n'y a que 71 tables et pleins de fonctionnalités et qu'on me presse pour que j'en rajoute.
Sinon j'aurai tout refais en partant de zéro.

Si vous saviez comme j'ai hâte que cette mission se termine...
Client sur ma black list c'est clair.

[MacFly58]

Bonsoir,

Si c'est la conception qui ne va pas, il faut dire à votre commanditaire que son SII a été construit par des amateurs, et qu'il conviendrait en toute logique de repartir de la planche à dessin.

Si le client préfère une rustine, son bateau continuera à prendre l'eau de toute part au fil des mois, et au finale ça coutera beaucoup plus cher en frais de maintenance, et le tout finira à la poubelle.

Si c'est bien présenté et argumenté, c'est facile à comprendre, et le commanditaire pourra décider. Si une maison est mal conçue et que la porte d'entrée est à 3 mètres de haut (cas réel) etc..., il est difficile de l'habiter.
La conception est une étape capitale. Trop d'informaticiens s'assoient dessus.

S'il n'a pas vraiment pas d'argent par exemple, il faudra tenter de lui mettre une rustine, tant bien que mal...
Mais il faudra lui rappeler que son entreprise prend un gros risque, car le bien de le plus précieux d'une entreprise, c'est sa base de données (bien qu'elle ne soit pas valorisée dans le bilan comptable!).


Bon courage à vous, je compatis.