Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 6 sur 6
  1. #1
    Membre Expert

    Homme Profil pro Gilles
    Enseignant
    Inscrit en
    novembre 2006
    Messages
    1 047
    Détails du profil
    Informations personnelles :
    Nom : Homme Gilles
    Âge : 56
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : novembre 2006
    Messages : 1 047
    Points : 1 148
    Points
    1 148

    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

  2. #2
    Membre chevronné
    Profil pro
    Inscrit en
    septembre 2010
    Messages
    291
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2010
    Messages : 291
    Points : 758
    Points
    758

    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 chevronné
    Profil pro
    Inscrit en
    septembre 2010
    Messages
    291
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2010
    Messages : 291
    Points : 758
    Points
    758

    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
    Membre Expert

    Homme Profil pro Gilles
    Enseignant
    Inscrit en
    novembre 2006
    Messages
    1 047
    Détails du profil
    Informations personnelles :
    Nom : Homme Gilles
    Âge : 56
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : novembre 2006
    Messages : 1 047
    Points : 1 148
    Points
    1 148

    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

  5. #5
    Membre Expert Avatar de wimbish
    Homme Profil pro Christophe Vibert
    Développeur informatique
    Inscrit en
    octobre 2006
    Messages
    411
    Détails du profil
    Informations personnelles :
    Nom : Homme Christophe Vibert
    Âge : 40
    Localisation : France, Manche (Basse Normandie)

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

    Informations forums :
    Inscription : octobre 2006
    Messages : 411
    Points : 1 033
    Points
    1 033

    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 chevronné
    Profil pro
    Inscrit en
    septembre 2010
    Messages
    291
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2010
    Messages : 291
    Points : 758
    Points
    758

    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.

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

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •