HF : Equivalent à UTC_DATE() +0 [Résolu]

[selzig]

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

[OnePoint]

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

[OnePoint]

Envoyé par selzig

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.

Envoyé par selzig

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

[selzig]

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

[wimbish]

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.

[OnePoint]

Bonjour,

Envoyé par selzig

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":

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.