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

HyperFileSQL Discussion :

HF : Equivalent à UTC_DATE() +0


Sujet :

HyperFileSQL

  1. #1
    Invité
    Invité(e)
    Par défaut HF : Equivalent à UTC_DATE() +0
    Bonjour,

    En HyperFile, existe-t-il un équivalent à UTC_DATE() +0 de mySQL [ou à partir de now() de PostgreSQL] que l'on peut directement insérer dans une requête SQL...
    ou est-on obligé de passer "extérieurement et donc faussement" par HInfoServeur(hfConnexion,hInfoDate) ?

    J'ai trouvé le document des commandes disponibles... SYSDATE... La valeur renvoyée est-elle identique à hInfoDate [Date et heure du serveur au format UTC (temps universel). Cette information est une chaîne de caractères du type "AAAAMMJJHHMMSS"] ?
    Si tel n'est pas le cas faut-il utiliser en complément NEW_TIME(Date, Fuseau Horaire 1, Fuseau Horaire 2). Et si oui comment ?

    Merci. Cordialement. Gilles
    Dernière modification par Invité ; 09/11/2012 à 17h04.

  2. #2
    Membre éclairé
    Profil pro
    Inscrit en
    Septembre 2010
    Messages
    303
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2010
    Messages : 303
    Points : 812
    Points
    812
    Par défaut
    Salut !

    Dans les requêtes SQL d'HyperFile, tu peux aussi utiliser des fonctions WLangage, si les fonctions SQL ne te donnent pas satisfaction.

    Pour savoir comment "Utiliser des fonctions WLangage dans des requêtes SQL pour HyperFileSQL" :
    http://doc.pcsoft.fr/fr-FR/?1513004&...te_sql#NOTE3_1

    Les fonctions WLangage qui peuvent être utiles :

    DateHeureLocaleVersUTC
    http://doc.pcsoft.fr/fr-FR/?3027036&...fonction&q=utc

    DateSys
    http://doc.pcsoft.fr/fr-FR/?3027026&...tesys_fonction


  3. #3
    Membre éclairé
    Profil pro
    Inscrit en
    Septembre 2010
    Messages
    303
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2010
    Messages : 303
    Points : 812
    Points
    812
    Par défaut
    Citation Envoyé par selzig Voir le message

    SYSDATE... La valeur renvoyée est-elle identique à hInfoDate [Date et heure du serveur au format UTC (temps universel).
    Dans Windev et HyperFileSQL, les dates sont locales, sans notion de fuseau horaire. Donc SYSDATE retourne la date locale courante.

    Citation Envoyé par selzig Voir le message
    Si tel n'est pas le cas faut-il utiliser en complément NEW_TIME(Date, Fuseau Horaire 1, Fuseau Horaire 2). Et si oui comment ?
    La fonction NEW_TIME est "nord-américano-centrique", donc sans grand intérêt pour une utilisation dans le reste du monde.

    Cf. documentation Oracle
    http://docs.oracle.com/cd/B19306_01/...nctions092.htm

  4. #4
    Invité
    Invité(e)
    Par défaut
    Bonjour,

    Je suis novice en Windev actuel puisque j'ai abandonné en 7.5. Cependant entre temps, j'ai continué à programmer et utilise régulièrement les SGDBR (mySQL et PostgreSQL) mais pas HyperFile évidemment. J'ai profité des vacances scolaires pour redécouvrir Windev.

    Alors SYSDATE est une fonction SQL donc que l'on place dans la requête SQL - si j'ai bien compris au même titre qu'un INSERT ou SELECT. (cf la Doc).

    Il ne s'agit pas de la fonction SysDate() de Windev. A ce titre la fonction SQL SYSDATE ne peut que renvoyer la date du serveur SQL puisque c'est une fonction euh... "embarquée" (calculée dynamiquement par le serveur SQL). Le serveur dans mon cas est un Linux amd64 hébergé (ie sur un serveur dédié chez un hébergeur) avec un HyperFile 17.

    Bon, finalement j'ai envoyé une requête d'INSERT pour tester avec SYSDATE :
    Une fois la requête exécutée, le champ "visé" contient 17 caractères 20121110124324213 soit 2012/11/10 -12:43:24,213 (au millième de seconde ?) Avant d'émettre la requête, le DateSys du poste local a été avancé d'une semaine (17/11/2012)... pour être sûr s'il y avait besoin . Donc la fonction SQL SYSDATE me conviendra.

    ------------------
    Autre petit problème rencontré : j'ai l'habitude d'utiliser une sorte de DateStamp contenant la date et l'heure du serveur plus une chaine aléatoire ASCII générée par la requête et donc définie en langage SQL dans celle-ci. Je ne vois pas ce genre de fonctions disponibles : il y a bien RANDOM et CONCAT (ou STRING_AGG)... et ASCII. Mais l'inverse d'ASCII, l'équivalent de Caract() en langage Windev, ne semble pas exister en SQL HF.

    Enfin dernier point, comment serait-il possible d'obtenir la même fonction en HAjoute sachant que la récupération de l'heure du serveur dans un premier temps puis l'injection dans une requête dans un second, ne répond pas du tout à la même problématique car l'heure indiquée sera inexacte... Le temps du transport de la réponse de l'heure + le temps de transport de la requête au serveur fausseront le résultat or j'ai besoin d'un timing fin. Dans l'état actuel de ma connaissance du produit et de ses commandes, cela exclut l'utilisation des fonctions Hxxx.

    De toute façon, ce dernier point n'est pas embêtant puisque je ne compte pas utiliser les fonctions Hxxxx. Et l'incapacité éventuelle de ne pas générer la chaine aléatoire de mon DateStamp spécifique non plus... On peut la générer avant l'envoi de la requête.

    Mais comme je fais le point, autant connaître les limites du produit.

    En conclusion, le problème est résolu. Mais je suis toujours preneur de réponses aux deux derniers points évoqués.

    Cordialement. Gilles
    Dernière modification par Invité ; 10/11/2012 à 13h58.

  5. #5
    Membre éprouvé Avatar de wimbish
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2006
    Messages
    416
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2006
    Messages : 416
    Points : 1 073
    Points
    1 073
    Par défaut
    Bonjour selzig,

    comment serait-il possible d'obtenir la même fonction en HAjoute sachant que la récupération de l'heure du serveur dans un premier temps puis l'injection dans une requête dans un second, ne répond pas du tout à la même problématique car l'heure indiquée sera inexacte... Le temps du transport de la réponse de l'heure + le temps de transport de la requête au serveur fausseront le résultat or j'ai besoin d'un timing fin
    Une piste ... , tu pourrais définir des fonctions d'ajout dans des procédures stockées afin de récupérer le datesys serveur juste avant l’écriture.
    Christophe.

    Tous les chemins mènent à Rome http://doc.pcsoft.fr/fr-FR/

  6. #6
    Membre éclairé
    Profil pro
    Inscrit en
    Septembre 2010
    Messages
    303
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2010
    Messages : 303
    Points : 812
    Points
    812
    Par défaut
    Bonjour,

    Citation Envoyé par selzig Voir le message

    Alors SYSDATE est une fonction SQL donc que l'on place dans la requête SQL - si j'ai bien compris au même titre qu'un INSERT ou SELECT. (cf la Doc).

    Il ne s'agit pas de la fonction SysDate() de Windev. A ce titre la fonction SQL SYSDATE ne peut que renvoyer la date du serveur SQL puisque c'est une fonction euh... "embarquée" (calculée dynamiquement par le serveur SQL). Le serveur dans mon cas est un Linux amd64 hébergé (ie sur un serveur dédié chez un hébergeur) avec un HyperFile 17.
    "embarquée" ?

    SYSDATE est une fonction SQL native.

    Les fonctions WLangage utilisées dans une requête SQL sont des fonctions "intégrées".

    En HyperFileSQL C/S, ces fonctions sont exécutées sur le serveur, qu'elles soient natives ou intégrées.

    Concernant les fonctions WLangages intégrées dans les requêtes SQL...
    (1) Utiliser des fonctions intégrées implique une rupture avec le "standard" SQL : en l'état, il n'est plus possible de porter la requête vers d'autres SGBDR SQL.
    (2) Il y a une limitation qui me "dérange":
    Citation Envoyé par Documentation
    Si la fonction WLangage est utilisée dans le SELECT, le type de la valeur renvoyée est un mémo texte.

Discussions similaires

  1. Réponses: 2
    Dernier message: 18/11/2002, 10h12
  2. equivalent à explode?
    Par djridou dans le forum Langage
    Réponses: 3
    Dernier message: 28/08/2002, 12h01
  3. [Kylix] Equivalent ShellExec en CLX
    Par Anonymous dans le forum EDI
    Réponses: 7
    Dernier message: 14/08/2002, 12h55
  4. Equivalent à ExeName pour une DLL
    Par Smortex dans le forum Langage
    Réponses: 7
    Dernier message: 16/07/2002, 22h07
  5. [Kylix] equivalent winsock avec kylix
    Par Victor dans le forum EDI
    Réponses: 2
    Dernier message: 08/05/2002, 08h43

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