J'ai une table qui se présente de la façon suivante :
idEmploye (numéro d'employe), idService (numéro de service), datdeb, datfin
(dates de début et de fin d'affectation à ce service).
Le service d'affectation en cours de l'employé est celui dont la date de fin
est au 01/01/2020 cela permet de ramener la datdeb pour calculer l'ancienneté
de l'employé dans son service.
Jusque là pas de problème. Maintenant ça se complique. Pour des raisons
illogiques un certain nombre d'employé ont eut un nouvel enregistrement à la
date du 01/01/2007 (datdeb) sans changement de service.
Comment faire pour retrouver la bonne datdeb en sachant que quelques
employés peuvent avoir eut un changement de service réel le 01/01/2007 ?
En gros max(datdeb) et lorsque datdeb = 01/01/2007 prendre datfin =
01/01/2007 lorsque le service est différent de datdeb = 01/01/2007
C'est encore un peu confus dans ma tête, et pour le traduire en SQL j'ai les
neurones qui bouillent (peut-être à cause d'une surcharge de cafeïne... une
petite tisane me ferait peut-être du bien)
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
Eric
Bonjour,
J'ai du mal à comprendre le problème. Pourquoi la date de fin doit elle être renseignée lors de l'enregistrement d'un salarié dans un service puisqu'on ne la connait pas ? Sans cette dernière, on peut, à tout moment, calculer l'ancienneté de service par rapport à la date du jour. Lors d'une mutation, il faut imposer de renseigner la date de fin du service de départ puis enregistrer le salarié dans son nouveau service avec la nouvelle date d'affectation. De cette manière, il ne devrait plus y avoir de problème, non ?
Pour en revenir à ta question, le SQL Suivant te donne la 1ère date d'affectation dans le service dans le cas où tu as 2 enregistrements au moins du même salarié dans le même service:
SELECT A.IdEmploye, A.IdService, A.DateDeb FROM Table1 A INNER JOIN Table1 B ON A.IdService = B.IdService AND A.IdEmploye = B.IdEmploye WHERE A.DateDeb<B.DateDeb;
Mais, il risque d'être insuffisant dans la mesure où un salarié peut être dans le service 1 pendant un an puis muter dans le service 2 pour 2 ans et revenir dans le service 1 avec ton histoire de date de fin mis au 01/01/2020.
Bonjour à tous et à toutes,
J'ai une table qui se présente de la façon suivante : idEmploye (numéro d'employe), idService (numéro de service), datdeb, datfin (dates de début et de fin d'affectation à ce service). Le service d'affectation en cours de l'employé est celui dont la date de fin est au 01/01/2020 cela permet de ramener la datdeb pour calculer l'ancienneté de l'employé dans son service. Jusque là pas de problème. Maintenant ça se complique. Pour des raisons illogiques un certain nombre d'employé ont eut un nouvel enregistrement à la date du 01/01/2007 (datdeb) sans changement de service. Comment faire pour retrouver la bonne datdeb en sachant que quelques employés peuvent avoir eut un changement de service réel le 01/01/2007 ?
En gros max(datdeb) et lorsque datdeb = 01/01/2007 prendre datfin = 01/01/2007 lorsque le service est différent de datdeb = 01/01/2007
C'est encore un peu confus dans ma tête, et pour le traduire en SQL j'ai les neurones qui bouillent (peut-être à cause d'une surcharge de cafeïne... une petite tisane me ferait peut-être du bien)
Merci à tous et à toutes de m'avoir lu jusqu'ici
-- A+ Eric http://www.mpfa.info/ Archives : http://groups.google.fr/group/microsoft.public.fr.access?hl=fr
Bonjour,
J'ai du mal à comprendre le problème.
Pourquoi la date de fin doit elle être renseignée lors de
l'enregistrement d'un salarié dans un service puisqu'on ne la connait
pas ? Sans cette dernière, on peut, à tout moment, calculer l'ancienneté
de service par rapport à la date du jour.
Lors d'une mutation, il faut imposer de renseigner la date de fin du
service de départ puis enregistrer le salarié dans son nouveau service
avec la nouvelle date d'affectation.
De cette manière, il ne devrait plus y avoir de problème, non ?
Pour en revenir à ta question, le SQL Suivant te donne la 1ère date
d'affectation dans le service dans le cas où tu as 2 enregistrements au
moins du même salarié dans le même service:
SELECT A.IdEmploye, A.IdService, A.DateDeb
FROM Table1 A
INNER JOIN Table1 B
ON A.IdService = B.IdService AND A.IdEmploye = B.IdEmploye
WHERE A.DateDeb<B.DateDeb;
Mais, il risque d'être insuffisant dans la mesure où un salarié peut
être dans le service 1 pendant un an puis muter dans le service 2 pour 2
ans et revenir dans le service 1 avec ton histoire de date de fin mis au
01/01/2020.
Bonjour à tous et à toutes,
J'ai une table qui se présente de la façon suivante :
idEmploye (numéro d'employe), idService (numéro de service), datdeb, datfin
(dates de début et de fin d'affectation à ce service).
Le service d'affectation en cours de l'employé est celui dont la date de fin
est au 01/01/2020 cela permet de ramener la datdeb pour calculer l'ancienneté
de l'employé dans son service.
Jusque là pas de problème. Maintenant ça se complique. Pour des raisons
illogiques un certain nombre d'employé ont eut un nouvel enregistrement à la
date du 01/01/2007 (datdeb) sans changement de service.
Comment faire pour retrouver la bonne datdeb en sachant que quelques
employés peuvent avoir eut un changement de service réel le 01/01/2007 ?
En gros max(datdeb) et lorsque datdeb = 01/01/2007 prendre datfin =
01/01/2007 lorsque le service est différent de datdeb = 01/01/2007
C'est encore un peu confus dans ma tête, et pour le traduire en SQL j'ai les
neurones qui bouillent (peut-être à cause d'une surcharge de cafeïne... une
petite tisane me ferait peut-être du bien)
Merci à tous et à toutes de m'avoir lu jusqu'ici
--
A+
Eric
http://www.mpfa.info/
Archives : http://groups.google.fr/group/microsoft.public.fr.access?hl=fr
J'ai du mal à comprendre le problème. Pourquoi la date de fin doit elle être renseignée lors de l'enregistrement d'un salarié dans un service puisqu'on ne la connait pas ? Sans cette dernière, on peut, à tout moment, calculer l'ancienneté de service par rapport à la date du jour. Lors d'une mutation, il faut imposer de renseigner la date de fin du service de départ puis enregistrer le salarié dans son nouveau service avec la nouvelle date d'affectation. De cette manière, il ne devrait plus y avoir de problème, non ?
Pour en revenir à ta question, le SQL Suivant te donne la 1ère date d'affectation dans le service dans le cas où tu as 2 enregistrements au moins du même salarié dans le même service:
SELECT A.IdEmploye, A.IdService, A.DateDeb FROM Table1 A INNER JOIN Table1 B ON A.IdService = B.IdService AND A.IdEmploye = B.IdEmploye WHERE A.DateDeb<B.DateDeb;
Mais, il risque d'être insuffisant dans la mesure où un salarié peut être dans le service 1 pendant un an puis muter dans le service 2 pour 2 ans et revenir dans le service 1 avec ton histoire de date de fin mis au 01/01/2020.
Bonjour à tous et à toutes,
J'ai une table qui se présente de la façon suivante : idEmploye (numéro d'employe), idService (numéro de service), datdeb, datfin (dates de début et de fin d'affectation à ce service). Le service d'affectation en cours de l'employé est celui dont la date de fin est au 01/01/2020 cela permet de ramener la datdeb pour calculer l'ancienneté de l'employé dans son service. Jusque là pas de problème. Maintenant ça se complique. Pour des raisons illogiques un certain nombre d'employé ont eut un nouvel enregistrement à la date du 01/01/2007 (datdeb) sans changement de service. Comment faire pour retrouver la bonne datdeb en sachant que quelques employés peuvent avoir eut un changement de service réel le 01/01/2007 ?
En gros max(datdeb) et lorsque datdeb = 01/01/2007 prendre datfin = 01/01/2007 lorsque le service est différent de datdeb = 01/01/2007
C'est encore un peu confus dans ma tête, et pour le traduire en SQL j'ai les neurones qui bouillent (peut-être à cause d'une surcharge de cafeïne... une petite tisane me ferait peut-être du bien)
Merci à tous et à toutes de m'avoir lu jusqu'ici
-- A+ Eric http://www.mpfa.info/ Archives : http://groups.google.fr/group/microsoft.public.fr.access?hl=fr
Eric
.../...
Bonjour,
J'ai du mal à comprendre le problème. Pourquoi la date de fin doit elle être renseignée lors de l'enregistrement d'un salarié dans un service puisqu'on ne la connait pas ? Sans cette dernière, on peut, à tout moment, calculer l'ancienneté de service par rapport à la date du jour.
Manque la phrase suivante : Le service actuel du salarié est celui pour lequel la date de fin n'est pas renseignée (Null).
[...]
Lors d'une mutation, il faut imposer de renseigner la date de fin du service de départ puis enregistrer le salarié dans son nouveau service avec la nouvelle date d'affectation.
Bonjour à tous et à toutes,
J'ai une table qui se présente de la façon suivante : idEmploye (numéro d'employe), idService (numéro de service), datdeb, datfin (dates de début et de fin d'affectation à ce service). Le service d'affectation en cours de l'employé est celui dont la date de fin est au 01/01/2020 cela permet de ramener la datdeb pour calculer l'ancienneté de l'employé dans son service. [...]
-- A+ Eric http://www.mpfa.info/ Archives : http://groups.google.fr/group/microsoft.public.fr.access?hl=fr
.../...
Bonjour,
J'ai du mal à comprendre le problème.
Pourquoi la date de fin doit elle être renseignée lors de
l'enregistrement d'un salarié dans un service puisqu'on ne la connait
pas ? Sans cette dernière, on peut, à tout moment, calculer l'ancienneté
de service par rapport à la date du jour.
Manque la phrase suivante :
Le service actuel du salarié est celui pour lequel la date
de fin n'est pas renseignée (Null).
[...]
Lors d'une mutation, il faut imposer de renseigner la date de fin du
service de départ puis enregistrer le salarié dans son nouveau service
avec la nouvelle date d'affectation.
Bonjour à tous et à toutes,
J'ai une table qui se présente de la façon suivante :
idEmploye (numéro d'employe), idService (numéro de service), datdeb,
datfin (dates de début et de fin d'affectation à ce service).
Le service d'affectation en cours de l'employé est celui dont la date
de fin est au 01/01/2020 cela permet de ramener la datdeb pour
calculer l'ancienneté de l'employé dans son service. [...]
--
A+
Eric
http://www.mpfa.info/
Archives : http://groups.google.fr/group/microsoft.public.fr.access?hl=fr
J'ai du mal à comprendre le problème. Pourquoi la date de fin doit elle être renseignée lors de l'enregistrement d'un salarié dans un service puisqu'on ne la connait pas ? Sans cette dernière, on peut, à tout moment, calculer l'ancienneté de service par rapport à la date du jour.
Manque la phrase suivante : Le service actuel du salarié est celui pour lequel la date de fin n'est pas renseignée (Null).
[...]
Lors d'une mutation, il faut imposer de renseigner la date de fin du service de départ puis enregistrer le salarié dans son nouveau service avec la nouvelle date d'affectation.
Bonjour à tous et à toutes,
J'ai une table qui se présente de la façon suivante : idEmploye (numéro d'employe), idService (numéro de service), datdeb, datfin (dates de début et de fin d'affectation à ce service). Le service d'affectation en cours de l'employé est celui dont la date de fin est au 01/01/2020 cela permet de ramener la datdeb pour calculer l'ancienneté de l'employé dans son service. [...]
-- A+ Eric http://www.mpfa.info/ Archives : http://groups.google.fr/group/microsoft.public.fr.access?hl=fr
Eric
Encore un oubli. Pardonnable car c'est le début du WE ;-)
Si la date du 01/01/2007 est impérative et non donnée en exemple il faut modifier le SQL comme suit:
SELECT A.IdEmploye, A.IdService, A.DateDeb FROM Table1 A INNER JOIN Table1 B ON A.IdEmploye = B.IdEmploye AND A.IdService = B.IdService WHERE A.DateDeb<B.DateDeb AND B.DateDeb=#01/01/2007#;
(Adapter bien sûr le nom de la table) -- A+ Eric http://www.mpfa.info/ Archives : http://groups.google.fr/group/microsoft.public.fr.access?hl=fr
Encore un oubli. Pardonnable car c'est le début du WE ;-)
Si la date du 01/01/2007 est impérative et non donnée en exemple
il faut modifier le SQL comme suit:
SELECT A.IdEmploye, A.IdService, A.DateDeb
FROM Table1 A INNER JOIN Table1 B
ON A.IdEmploye = B.IdEmploye AND A.IdService = B.IdService
WHERE A.DateDeb<B.DateDeb AND B.DateDeb=#01/01/2007#;
(Adapter bien sûr le nom de la table)
--
A+
Eric
http://www.mpfa.info/
Archives : http://groups.google.fr/group/microsoft.public.fr.access?hl=fr
Encore un oubli. Pardonnable car c'est le début du WE ;-)
Si la date du 01/01/2007 est impérative et non donnée en exemple il faut modifier le SQL comme suit:
SELECT A.IdEmploye, A.IdService, A.DateDeb FROM Table1 A INNER JOIN Table1 B ON A.IdEmploye = B.IdEmploye AND A.IdService = B.IdService WHERE A.DateDeb<B.DateDeb AND B.DateDeb=#01/01/2007#;
(Adapter bien sûr le nom de la table) -- A+ Eric http://www.mpfa.info/ Archives : http://groups.google.fr/group/microsoft.public.fr.access?hl=fr
Bret
Merci Eric pour ta détermination
Le WE a porté conseil, je suppose que c'est l'éloignement de mon cerveau par rapport à une certaine puce qui se trouve dans un certain pc.
La solution que j'ai trouvée tient en 2 requêtes :
select idEmploye, idService, min(datdeb) as debut, max(datfin) as fin from table1 group by 1,2
select * from requete1 where fin = '01.01.2020'
Du coup j'élimine d'autres enregistrements parasites parce qu'il y avait bien d'autres raisons qu'un changement de service qui généraient un enregistrement dans la table service.
La date de fin n'est pas à null pour des raisons historiques qui doivent tenir à ça : il y avait des encore plus nuls que moi qui ne savaient pas gérer les null.
Encore merci pour le principe de la solution que je réutiliserait certainement dans d'autres circonstances.
Encore un oubli. Pardonnable car c'est le début du WE ;-)
Si la date du 01/01/2007 est impérative et non donnée en exemple il faut modifier le SQL comme suit:
SELECT A.IdEmploye, A.IdService, A.DateDeb FROM Table1 A INNER JOIN Table1 B ON A.IdEmploye = B.IdEmploye AND A.IdService = B.IdService WHERE A.DateDeb<B.DateDeb AND B.DateDeb=#01/01/2007#;
(Adapter bien sûr le nom de la table) -- A+ Eric http://www.mpfa.info/ Archives : http://groups.google.fr/group/microsoft.public.fr.access?hl=fr
Merci Eric pour ta détermination
Le WE a porté conseil, je suppose que c'est l'éloignement de mon cerveau par
rapport à une certaine puce qui se trouve dans un certain pc.
La solution que j'ai trouvée tient en 2 requêtes :
select idEmploye, idService, min(datdeb) as debut, max(datfin) as fin
from table1
group by 1,2
select * from requete1 where fin = '01.01.2020'
Du coup j'élimine d'autres enregistrements parasites parce qu'il y avait
bien d'autres raisons qu'un changement de service qui généraient un
enregistrement dans la table service.
La date de fin n'est pas à null pour des raisons historiques qui doivent
tenir à ça : il y avait des encore plus nuls que moi qui ne savaient pas
gérer les null.
Encore merci pour le principe de la solution que je réutiliserait
certainement dans d'autres circonstances.
Encore un oubli. Pardonnable car c'est le début du WE ;-)
Si la date du 01/01/2007 est impérative et non donnée en exemple
il faut modifier le SQL comme suit:
SELECT A.IdEmploye, A.IdService, A.DateDeb
FROM Table1 A INNER JOIN Table1 B
ON A.IdEmploye = B.IdEmploye AND A.IdService = B.IdService
WHERE A.DateDeb<B.DateDeb AND B.DateDeb=#01/01/2007#;
(Adapter bien sûr le nom de la table)
--
A+
Eric
http://www.mpfa.info/
Archives : http://groups.google.fr/group/microsoft.public.fr.access?hl=fr
Le WE a porté conseil, je suppose que c'est l'éloignement de mon cerveau par rapport à une certaine puce qui se trouve dans un certain pc.
La solution que j'ai trouvée tient en 2 requêtes :
select idEmploye, idService, min(datdeb) as debut, max(datfin) as fin from table1 group by 1,2
select * from requete1 where fin = '01.01.2020'
Du coup j'élimine d'autres enregistrements parasites parce qu'il y avait bien d'autres raisons qu'un changement de service qui généraient un enregistrement dans la table service.
La date de fin n'est pas à null pour des raisons historiques qui doivent tenir à ça : il y avait des encore plus nuls que moi qui ne savaient pas gérer les null.
Encore merci pour le principe de la solution que je réutiliserait certainement dans d'autres circonstances.
Encore un oubli. Pardonnable car c'est le début du WE ;-)
Si la date du 01/01/2007 est impérative et non donnée en exemple il faut modifier le SQL comme suit:
SELECT A.IdEmploye, A.IdService, A.DateDeb FROM Table1 A INNER JOIN Table1 B ON A.IdEmploye = B.IdEmploye AND A.IdService = B.IdService WHERE A.DateDeb<B.DateDeb AND B.DateDeb=#01/01/2007#;
(Adapter bien sûr le nom de la table) -- A+ Eric http://www.mpfa.info/ Archives : http://groups.google.fr/group/microsoft.public.fr.access?hl=fr
