Un fil précédent me fait penser à la problématique du format de stockage des
temps dans Access.
1/ le format date/time
Comme dans Excel, Access stocke les heures en fraction de journée. C'est un
peu une Lapalissade : 12 heures égale 1/2 jour, 1 heure 1/24ème et ainsi de
suite pour les minutes secondes.
Le 1er jour (1) est le 1er Janvier 1900.
une valeur comme 0.5 n'est pas encore le 1er janvier...
1.5 est le 1er janvier 1900 à 12 heures, soit 36 heures.
Excel possède un format d'affichage ( H M ou S entre [] )qui permet
d'afficher plus de 24 heures, mais pas Access.
Il faut passer par une fonction du style
[code]
Public Function FnFormatH(Total As Date) As String
'formate (en chaine) les heures / minutes >= 24:00
Dim nHeures As Double
Dim Nminutes As Double
If Total = 0 Then
FnFormatH = ""
Exit Function
End If
Nminutes = Total * 1440
nHeures = Int(Nminutes / 60)
Nminutes = Round(Nminutes - nHeures * 60)
If Nminutes = 60 Then 'à cause de l'arrondi
Nminutes = 0
nHeures = nHeures + 1
End If
FnFormatH = Trim(Str(nHeures)) & ":" & Format(Nminutes, "00")
End Function
[/code]
2/ de l'encodage
Un champ du type date/time est agréable à paramêtrer, à utiliser (l'encodage
est naturel) et permet de stocker la valeur sans traitement intermédiaire.
Il est incroyable de voir le nombre d'entreprises qui encodent des temps (ou
durées) sous forme fractionnaire (17 minutes = 0.283, 18 minutes = 0.3,
etc.), et ce, même dans Excel !
Lorsque mon application débarque, certains iraient jusqu'à baiser mes pieds
(j'exagère mais ...des louanges pour pouvoir taper 0:17 au lieu de 0.283
après avoit regardé une demi-page jaunie)
2 bis/
Tout cela fonctionne bien lorsqu'il s'agit d'encoder le temps de travail
d'opérateurs pour telle ou telle tâche qui ne dépassera jamais les 24
heures. Car c'est là la faiblesse : encoder une durée supérieure à 24
heures...
3/ Migration SQL SERVER
Ah ! Le 1er janvier 1900 devient le 30 décembre 1899. L'occasion de penser
à ma grand-mère adorée, Adrienne (née dans ce siècle). Mais cela fait DEUX
jours de différence !
un 0.5 devient -1.5.
Bon jai résolu le blème par diverses TSQL, mais quand même ...
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 blaise,
blaise cacramp wrote:
Un fil précédent me fait penser à la problématique du format de stockage des temps dans Access.
1/ le format date/time 2/ de l'encodage 2 bis/ 3/ Migration SQL SERVER
--------------
Et alors ?
heu... on devrait voir une question ? :-))
En fait, Access ne connait que le champ Date/Heure Il ne mémorise qu'un instant, pas une durée.
Néanmoins, on peut tout de même manipuler ces "heures" ainsi sauvée par une ch'tit fonction: http://www.3stone.be/access/faq.php?lng=fr&pg!16
Mais, étant donné ce que représente le champ "heure" pour Access, si la "durée" (qui n'existe pas sur Access) risque de dépasser les 24 heures ne fusse que 1 heure (et je le rappelle qu'il serait alors 1 heure du matin) il faut tout simplement utiliser le format utilisé également par la fonction Now() c. à d. "date et heure".
Ainsi, c'est un jeux d'enfant pour connaitre le temps écoulé entre le "10-08-2010 10:35" et "28-08-2010 3:42" à, l'aide d'un simple DateDiff()
Un fil précédent me fait penser à la problématique du format de
stockage des temps dans Access.
1/ le format date/time
2/ de l'encodage
2 bis/
3/ Migration SQL SERVER
--------------
Et alors ?
heu... on devrait voir une question ? :-))
En fait, Access ne connait que le champ Date/Heure
Il ne mémorise qu'un instant, pas une durée.
Néanmoins, on peut tout de même manipuler ces
"heures" ainsi sauvée par une ch'tit fonction:
http://www.3stone.be/access/faq.php?lng=fr&pg!16
Mais, étant donné ce que représente le champ "heure"
pour Access, si la "durée" (qui n'existe pas sur Access)
risque de dépasser les 24 heures ne fusse que 1 heure
(et je le rappelle qu'il serait alors 1 heure du matin)
il faut tout simplement utiliser le format utilisé également
par la fonction Now() c. à d. "date et heure".
Ainsi, c'est un jeux d'enfant pour connaitre le temps
écoulé entre le "10-08-2010 10:35" et "28-08-2010 3:42"
à, l'aide d'un simple DateDiff()
Un fil précédent me fait penser à la problématique du format de stockage des temps dans Access.
1/ le format date/time 2/ de l'encodage 2 bis/ 3/ Migration SQL SERVER
--------------
Et alors ?
heu... on devrait voir une question ? :-))
En fait, Access ne connait que le champ Date/Heure Il ne mémorise qu'un instant, pas une durée.
Néanmoins, on peut tout de même manipuler ces "heures" ainsi sauvée par une ch'tit fonction: http://www.3stone.be/access/faq.php?lng=fr&pg!16
Mais, étant donné ce que représente le champ "heure" pour Access, si la "durée" (qui n'existe pas sur Access) risque de dépasser les 24 heures ne fusse que 1 heure (et je le rappelle qu'il serait alors 1 heure du matin) il faut tout simplement utiliser le format utilisé également par la fonction Now() c. à d. "date et heure".
Ainsi, c'est un jeux d'enfant pour connaitre le temps écoulé entre le "10-08-2010 10:35" et "28-08-2010 3:42" à, l'aide d'un simple DateDiff()
"3stone" a écrit dans le message de news: i3sbjm$ic5$
Salut blaise,
blaise cacramp wrote:
Un fil précédent me fait penser à la problématique du format de stockage des temps dans Access.
1/ le format date/time 2/ de l'encodage 2 bis/ 3/ Migration SQL SERVER
--------------
Et alors ?
heu... on devrait voir une question ? :-))
Excuse-moi pour le délai de réponse, je voulais un peu de réflexion et me relire (c'est vacances et les apéros...).
Question / discussion / construction ... Je me suis fais une fois rabrouer parce que j'utilisais le format date/heure pour des durées. Alors je désire éclaircir le sujet.
En fait, Access ne connait que le champ Date/Heure Il ne mémorise qu'un instant, pas une durée.
Néanmoins, on peut tout de même manipuler ces "heures" ainsi sauvée par une ch'tit fonction: http://www.3stone.be/access/faq.php?lng=fr&pg!16
Mais, étant donné ce que représente le champ "heure" pour Access, si la "durée" (qui n'existe pas sur Access) risque de dépasser les 24 heures ne fusse que 1 heure (et je le rappelle qu'il serait alors 1 heure du matin) il faut tout simplement utiliser le format utilisé également par la fonction Now() c. à d. "date et heure".
Ainsi, c'est un jeux d'enfant pour connaitre le temps écoulé entre le "10-08-2010 10:35" et "28-08-2010 3:42" à, l'aide d'un simple DateDiff()
Une durée, c'est bien entendu la différence entre deux instants. Access comme Excel stockent ces "instants" sous une même forme numérique. Si on tape 12:00 dans Excel, il stocke 0,5. Dans Access aussi. Dès lors cet "instant" peut être une durée. La GROSSE différence entre Excel et Access est que dans le 1er je peux taper 25:00 et pas dans le second... Faut dire que, pour le moment, cela ne me dérange pas vraiment parce que les temps encodés dans mes différentes applications logistiques correspondent à des heures homme/travail qui ne peuvent pas légalement dépasser 9 heures.
Mais ainsi, je peux *directement* additionner, soustraire, multiplier ces durées et donc calculer des normes, des coûts et plein d'autres choses !
L'arrivée d'Access 2007 nous a posé des problèmes de sécurité d'accès aux données des dorsales, d'où le passage à SQL SERVER. C'est quand même un choc culturel : imagine que je ne parle *QUE* le patois (Picard en l'occurence) depuis toujours et longtemps, et que je doive me mettre au "bon" français. Quel problème ? Le patois possède des expressions imagées, elliptiques ou qui sont parfois difficilement traduisibles.
En SQL SERVER les dates et heures doivent d'abord être converties en nombres avant de pouvoir être additionnées, & Cie
Bien à toi, Blaise
Bonjour Triple Pierre ;-)
"3stone" <sweet@home.be> a écrit dans le message de news:
i3sbjm$ic5$1@speranza.aioe.org...
Salut blaise,
blaise cacramp wrote:
Un fil précédent me fait penser à la problématique du format de
stockage des temps dans Access.
1/ le format date/time
2/ de l'encodage
2 bis/
3/ Migration SQL SERVER
--------------
Et alors ?
heu... on devrait voir une question ? :-))
Excuse-moi pour le délai de réponse, je voulais un peu de réflexion et me
relire (c'est vacances et les apéros...).
Question / discussion / construction ... Je me suis fais une fois rabrouer
parce que j'utilisais le format date/heure pour des durées. Alors je désire
éclaircir le sujet.
En fait, Access ne connait que le champ Date/Heure
Il ne mémorise qu'un instant, pas une durée.
Néanmoins, on peut tout de même manipuler ces
"heures" ainsi sauvée par une ch'tit fonction:
http://www.3stone.be/access/faq.php?lng=fr&pg!16
Mais, étant donné ce que représente le champ "heure"
pour Access, si la "durée" (qui n'existe pas sur Access)
risque de dépasser les 24 heures ne fusse que 1 heure
(et je le rappelle qu'il serait alors 1 heure du matin)
il faut tout simplement utiliser le format utilisé également
par la fonction Now() c. à d. "date et heure".
Ainsi, c'est un jeux d'enfant pour connaitre le temps
écoulé entre le "10-08-2010 10:35" et "28-08-2010 3:42"
à, l'aide d'un simple DateDiff()
Une durée, c'est bien entendu la différence entre deux instants. Access
comme Excel stockent ces "instants" sous une même forme numérique. Si on
tape 12:00 dans Excel, il stocke 0,5. Dans Access aussi.
Dès lors cet "instant" peut être une durée. La GROSSE différence entre
Excel et Access est que dans le 1er je peux taper 25:00 et pas dans le
second...
Faut dire que, pour le moment, cela ne me dérange pas vraiment parce que les
temps encodés dans mes différentes applications logistiques correspondent à
des heures homme/travail qui ne peuvent pas légalement dépasser 9 heures.
Mais ainsi, je peux *directement* additionner, soustraire, multiplier ces
durées et donc
calculer des normes, des coûts et plein d'autres choses !
L'arrivée d'Access 2007 nous a posé des problèmes de sécurité d'accès aux
données des dorsales, d'où le passage à SQL SERVER.
C'est quand même un choc culturel : imagine que je ne parle *QUE* le patois
(Picard en l'occurence) depuis toujours et longtemps, et que je doive me
mettre au "bon" français.
Quel problème ? Le patois possède des expressions imagées, elliptiques ou
qui sont parfois difficilement traduisibles.
En SQL SERVER les dates et heures doivent d'abord être converties en nombres
avant de pouvoir être additionnées, & Cie
"3stone" a écrit dans le message de news: i3sbjm$ic5$
Salut blaise,
blaise cacramp wrote:
Un fil précédent me fait penser à la problématique du format de stockage des temps dans Access.
1/ le format date/time 2/ de l'encodage 2 bis/ 3/ Migration SQL SERVER
--------------
Et alors ?
heu... on devrait voir une question ? :-))
Excuse-moi pour le délai de réponse, je voulais un peu de réflexion et me relire (c'est vacances et les apéros...).
Question / discussion / construction ... Je me suis fais une fois rabrouer parce que j'utilisais le format date/heure pour des durées. Alors je désire éclaircir le sujet.
En fait, Access ne connait que le champ Date/Heure Il ne mémorise qu'un instant, pas une durée.
Néanmoins, on peut tout de même manipuler ces "heures" ainsi sauvée par une ch'tit fonction: http://www.3stone.be/access/faq.php?lng=fr&pg!16
Mais, étant donné ce que représente le champ "heure" pour Access, si la "durée" (qui n'existe pas sur Access) risque de dépasser les 24 heures ne fusse que 1 heure (et je le rappelle qu'il serait alors 1 heure du matin) il faut tout simplement utiliser le format utilisé également par la fonction Now() c. à d. "date et heure".
Ainsi, c'est un jeux d'enfant pour connaitre le temps écoulé entre le "10-08-2010 10:35" et "28-08-2010 3:42" à, l'aide d'un simple DateDiff()
Une durée, c'est bien entendu la différence entre deux instants. Access comme Excel stockent ces "instants" sous une même forme numérique. Si on tape 12:00 dans Excel, il stocke 0,5. Dans Access aussi. Dès lors cet "instant" peut être une durée. La GROSSE différence entre Excel et Access est que dans le 1er je peux taper 25:00 et pas dans le second... Faut dire que, pour le moment, cela ne me dérange pas vraiment parce que les temps encodés dans mes différentes applications logistiques correspondent à des heures homme/travail qui ne peuvent pas légalement dépasser 9 heures.
Mais ainsi, je peux *directement* additionner, soustraire, multiplier ces durées et donc calculer des normes, des coûts et plein d'autres choses !
L'arrivée d'Access 2007 nous a posé des problèmes de sécurité d'accès aux données des dorsales, d'où le passage à SQL SERVER. C'est quand même un choc culturel : imagine que je ne parle *QUE* le patois (Picard en l'occurence) depuis toujours et longtemps, et que je doive me mettre au "bon" français. Quel problème ? Le patois possède des expressions imagées, elliptiques ou qui sont parfois difficilement traduisibles.
En SQL SERVER les dates et heures doivent d'abord être converties en nombres avant de pouvoir être additionnées, & Cie
Bien à toi, Blaise
3stone
Salut,
blaise cacramp wrote: [...]
Une durée, c'est bien entendu la différence entre deux instants. Access comme Excel stockent ces "instants" sous une même forme numérique. Si on tape 12:00 dans Excel, il stocke 0,5. Dans Access aussi.
Oui, mais il ne faut pas trop s'occuper du fait qu'en interne c'est une valeur numérique que l'un et l'autre stocke... mais ce qu'il en fait. C'est la raison pour laquelle il ne faut pas utiliser ces numériques pour faire de savants calculs... qui peuvent donner un résultat faux.
Je me souviens d'une discussion sur le sujet (il y a... longtemps) avec entre-autre Michel Walsh et la surprise de certains qu'en au résultat faux obtenu. Le genre de mauvaise méthode comme x / 365,25 pour obtenir le nombre d'années... ce qui n'est qu'une approximation :-/
Dès lors cet "instant" peut être une durée. La GROSSE différence entre Excel et Access est que dans le 1er je peux taper 25:00 et pas dans le second...
Le 13 aout 2010 25:35 est une abération pour Access ;-) Et tout simplement, parce que Access utilise un seul et même champ (et format de champ) pour sauver la date ET l'heure. La seule "astuce" Made by Microsoft, est que lorsque tu ne sauve dans un tel champ QUE la date (fonction Date() ) il ne t'affichera QUE la date. Idem pour l'heure... Alors que si tu sauves la date ET l'heure (fonction Now(), il t'affichera toujours les deux, quoique tu saisisses par la suite dans ce champ. Pourtant le format interne sera identique et unique pour les trois! :)
Faut dire que, pour le moment, cela ne me dérange pas vraiment parce que les temps encodés dans mes différentes applications logistiques correspondent à des heures homme/travail qui ne peuvent pas légalement dépasser 9 heures.
Mais ainsi, je peux *directement* additionner, soustraire, multiplier ces durées et donc calculer des normes, des coûts et plein d'autres choses !
C'est bien pourquoi, lorsqu'il s'agit de manipuler des heures (durées), il est préférable d'utiliser directement un champ numérique et d'y sauver des... minutes !! Une petite fonction se charge de la conversion et mise en forme pour l'utilisateur.
En SQL SERVER les dates et heures doivent d'abord être converties en nombres avant de pouvoir être additionnées, & Cie
Une durée, c'est bien entendu la différence entre deux instants.
Access comme Excel stockent ces "instants" sous une même forme
numérique. Si on tape 12:00 dans Excel, il stocke 0,5. Dans Access
aussi.
Oui, mais il ne faut pas trop s'occuper du fait qu'en interne
c'est une valeur numérique que l'un et l'autre stocke...
mais ce qu'il en fait.
C'est la raison pour laquelle il ne faut pas utiliser ces numériques
pour faire de savants calculs... qui peuvent donner un résultat faux.
Je me souviens d'une discussion sur le sujet (il y a... longtemps)
avec entre-autre Michel Walsh et la surprise de certains qu'en
au résultat faux obtenu.
Le genre de mauvaise méthode comme x / 365,25 pour obtenir
le nombre d'années... ce qui n'est qu'une approximation :-/
Dès lors cet "instant" peut être une durée. La GROSSE différence
entre Excel et Access est que dans le 1er je peux taper 25:00 et pas
dans le second...
Le 13 aout 2010 25:35 est une abération pour Access ;-)
Et tout simplement, parce que Access utilise un seul et même
champ (et format de champ) pour sauver la date ET l'heure.
La seule "astuce" Made by Microsoft, est que lorsque tu
ne sauve dans un tel champ QUE la date (fonction Date() )
il ne t'affichera QUE la date. Idem pour l'heure...
Alors que si tu sauves la date ET l'heure (fonction Now(),
il t'affichera toujours les deux, quoique tu saisisses par la
suite dans ce champ. Pourtant le format interne sera
identique et unique pour les trois! :)
Faut dire que, pour le moment, cela ne me dérange pas vraiment parce
que les temps encodés dans mes différentes applications logistiques
correspondent à des heures homme/travail qui ne peuvent pas
légalement dépasser 9 heures.
Mais ainsi, je peux *directement* additionner, soustraire, multiplier
ces durées et donc
calculer des normes, des coûts et plein d'autres choses !
C'est bien pourquoi, lorsqu'il s'agit de manipuler des heures (durées),
il est préférable d'utiliser directement un champ numérique et
d'y sauver des... minutes !!
Une petite fonction se charge de la conversion et mise en forme
pour l'utilisateur.
En SQL SERVER les dates et heures doivent d'abord être converties en
nombres avant de pouvoir être additionnées, & Cie
Une durée, c'est bien entendu la différence entre deux instants. Access comme Excel stockent ces "instants" sous une même forme numérique. Si on tape 12:00 dans Excel, il stocke 0,5. Dans Access aussi.
Oui, mais il ne faut pas trop s'occuper du fait qu'en interne c'est une valeur numérique que l'un et l'autre stocke... mais ce qu'il en fait. C'est la raison pour laquelle il ne faut pas utiliser ces numériques pour faire de savants calculs... qui peuvent donner un résultat faux.
Je me souviens d'une discussion sur le sujet (il y a... longtemps) avec entre-autre Michel Walsh et la surprise de certains qu'en au résultat faux obtenu. Le genre de mauvaise méthode comme x / 365,25 pour obtenir le nombre d'années... ce qui n'est qu'une approximation :-/
Dès lors cet "instant" peut être une durée. La GROSSE différence entre Excel et Access est que dans le 1er je peux taper 25:00 et pas dans le second...
Le 13 aout 2010 25:35 est une abération pour Access ;-) Et tout simplement, parce que Access utilise un seul et même champ (et format de champ) pour sauver la date ET l'heure. La seule "astuce" Made by Microsoft, est que lorsque tu ne sauve dans un tel champ QUE la date (fonction Date() ) il ne t'affichera QUE la date. Idem pour l'heure... Alors que si tu sauves la date ET l'heure (fonction Now(), il t'affichera toujours les deux, quoique tu saisisses par la suite dans ce champ. Pourtant le format interne sera identique et unique pour les trois! :)
Faut dire que, pour le moment, cela ne me dérange pas vraiment parce que les temps encodés dans mes différentes applications logistiques correspondent à des heures homme/travail qui ne peuvent pas légalement dépasser 9 heures.
Mais ainsi, je peux *directement* additionner, soustraire, multiplier ces durées et donc calculer des normes, des coûts et plein d'autres choses !
C'est bien pourquoi, lorsqu'il s'agit de manipuler des heures (durées), il est préférable d'utiliser directement un champ numérique et d'y sauver des... minutes !! Une petite fonction se charge de la conversion et mise en forme pour l'utilisateur.
En SQL SERVER les dates et heures doivent d'abord être converties en nombres avant de pouvoir être additionnées, & Cie
