IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Requêtes MySQL Discussion :

Pourquoi SEC_TO_TIME renvoie NULL si la durée est inférieur à 1h ?


Sujet :

Requêtes MySQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éprouvé
    Avatar de clavier12AZQSWX
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Avril 2009
    Messages
    1 478
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : Avril 2009
    Messages : 1 478
    Par défaut Pourquoi SEC_TO_TIME renvoie NULL si la durée est inférieur à 1h ?
    bonjour,

    j'essaie de faire la somme en durée horaire de 2 champs dont le format est time (une heure de début et une heure de fin).
    Curieusement, quand fin-debut<3600, ça affiche null alors que dès que je passe le pallier d'1h (donc 3599 sec), ça marche bien.

    exemple de ma requête:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    SELECT SEC_TO_TIME(SUM(TIME_TO_SEC(edt_heure_fin-edt_heure_debut))) AS Duree
    FROM edt
    quand edt_heure_fin="09:00:00" et edt_heure_debut="08:30:00" (soit 30min) ça renvoie Null au lieu de 00:30:00
    quand edt_heure_fin="09:29:00" et edt_heure_debut="08:30:00" (soit 59min) ça renvoie encore null au lieu 00:59:00

    quand edt_heure_fin="09:30:00" et edt_heure_debut="08:30:00" (soit 1h) ça renvoie bien 01:00:00
    quand edt_heure_fin="09:31:00" et edt_heure_debut="08:30:00" (soit 1h01min) ça renvoie bien 01:01:00

    Vraiment bizarre...
    d'autant plus le pallier 3601s fonctionne bien !

    Avez-vous une idée du problème ?

  2. #2
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 633
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 633
    Billets dans le blog
    10
    Par défaut
    bonjour,

    Avec cette requête, le résultat devrait être plus convaincant :

    select sec_to_time(time_to_sec(edt_fin)-time_to_sec(edt_deb)) as duree.

    ou tout simplement

    select timediff(edt_fin, edt_deb)

  3. #3
    Membre éprouvé
    Avatar de clavier12AZQSWX
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Avril 2009
    Messages
    1 478
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : Avril 2009
    Messages : 1 478
    Par défaut
    bonjour et merci pour votre aide, je vais essayer.
    ce que je déduis de votre aide, c'est qu'il n'existe pas d'opérateur "-" implicite pour les champs de type TIME ? il faut obligatoirement utiliser la fonction Timediff ?
    https://www.w3schools.com/sql/func_mysql_timediff.asp

    est-ce que ça veut dire que mysql faisait une "différence" de string dans mon cas initial , du moins dans certains cas ?
    Quand on lui donne 2 champs TIME, il ne comprend pas ?

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 010
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 010
    Billets dans le blog
    6
    Par défaut
    Une donnée de type "temps" n'a rien à voir avec une quantité !
    Que donnerais la soustraction du 1er janvier 1803 au 14 juillet 2015 selon vous ?
    Même chose pour les chaines de caractères...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  5. #5
    Membre éprouvé
    Avatar de clavier12AZQSWX
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Avril 2009
    Messages
    1 478
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : Avril 2009
    Messages : 1 478
    Par défaut
    bonjour,

    ok c'est résolu.

    timediff fait l'affaire.
    étrangement je ne comprends pas pourquoi mon SUM ( timedif (x,y)) renvoie une sum en secondes plutôt qu'en format TIME comme les 2 champs concernés.
    du coup, je suis obligé de faire SEC_TO_TIME(SUM(TIMEDIFF(edt_heure_fin, edt_heure_debut))).

    Une SUM d'un TYPE, devrait renvoyer une valeur dans le même type, étrangement comportement de Mysql ici car il me renvoie des secondes.

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 010
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 010
    Billets dans le blog
    6
    Par défaut
    MySQL est le SGBDR le plus bugué. Aucun SGBD digne de ce nom ne peut faire des SUM sur d'autres types de données que des nombres. Ceci est d'ailleurs formellement interdit par la norme SQL.
    Dès lors MySQL fait n'importe quoi ce qui donne des résultats faux !

    A lire :
    https://sqlpro.developpez.com/tutori...mysql-mariadb/
    https://www.developpez.net/forums/d2...lnerable-mode/


    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Requête SQL qui ne renvoie rien quand la valeur est nulle
    Par vocal94130 dans le forum Requêtes
    Réponses: 4
    Dernier message: 01/09/2010, 14h11
  2. [MFC]Pourquoi CreateNewFrame() renvoie NULL en RELEASE.
    Par Gabrielly dans le forum Visual C++
    Réponses: 4
    Dernier message: 16/08/2007, 21h55
  3. [SPL] Rewind() qui renvoie NULL
    Par fadeninev dans le forum Bibliothèques et frameworks
    Réponses: 6
    Dernier message: 06/06/2006, 15h44
  4. erreur de valaur nulle..qui ne l'est pas :-(
    Par bachilbouzouk dans le forum ASP
    Réponses: 7
    Dernier message: 20/04/2005, 08h52
  5. [JDBC]Un new qui renvoie null...
    Par Ditch dans le forum JDBC
    Réponses: 4
    Dernier message: 03/01/2005, 13h14

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo