Bonjour,

Franchement, je ne sais pas si c'est possible sans passer par un userobjet non visuel.
Parceque là, tu souhaites carrément remplacer la fonction PB générique par deux fonctions customisées.

Pour info, chez mon précédent client, ils avaient surchargé le SQLCA avec une fonction fnv_getsysdatetime
que l'on utilisait systématiquement à la place de la fonction Today()
(Cela dit, je comprends que tu ne veuilles pas repasser dans toutes tes PBL pour remplacer les références à Today)

Salut, je crois qu'en PB les fonctions de même nom se différencient uniquement par le nb/type d'arguments.

Finding and executing functions and events

PowerBuilder looks for a matching function or event based on its name and its argument list. (...)

si ta fonction personnalisée Today() renvoie un datetime et que tu veux une date tu peux faire un simple Date( Today() )

Le souci avec ton approche, c'est à la base ta volonté de créer deux fonctions globales de même nom. Une fonction globale dans PowerBuilder, c'est une classe au même titre qu'une fenêtre ou une datawindow, et pas une méthode (de quel objet ?) que tu pourrais surcharger.
Tu peux effectivement créer deux fonctions globales de même nom, obligatoirement dans deux pbl différentes. Dans ce cas c'est comme d'habitude la première dans l'ordre de recherche qui sera utilisée, et celle-ci seulement.

La meilleure solution à ton problème (récupérer l'heure de ton serveur Oracle et pas celle de ton poste client), c'est celle de foon. Crée une classe qui hérite de Transaction, avec une méthode supplémentaire pour récupérer un Datetime. Tu pourras convertir de façon explicite ce Datetime en Date au besoin, ce qui rend en plus ton code plus facile à maintenir en évitant au relecteur de se poser la question.
Si besoin, tu peux aussi créer une fonction globale Today, qui appelle la méthode de ta classe Transaction personnalisée (ou génère systématiquement une erreur si tu veux être méchant avec tes collègues développeurs ).

rincevent a écrit:

FMolinas, quitte à ne pouvoir avoir qu'une version de la fcontion today je ne pige pas l'intérêt de la définir comme fct° d'un objet ? (autant utiliser direct une fct Globale) et je comprends encore moins pourquoi tu parles d'hériter de l'objet transaction, peux tu m'expliquer ?

Pour l'utilisation d'un userobject hérité de l'objet transaction, la réponse est simple: La base de donnée!

En effet, si tu veux récupérer la date système, tu dois aller la chercher via ton SGBD (avec des instructions différentes d'un SGBD à l'autre: SYSDATE pour ORACLE, GETDATE() pour SYBASE par exemple).

Maintenant, imagine que tu dois taper sur 2 SGBD différents au sein d'une même application (Une base ORACLE et une base SQLAnywhere par exemple): Si tu veux récupérer la date système sur l'un ou l'autre serveur, il va te falloir deux fonctions globales différentes (avec les problèmes que tu as toi même soulevé car elles devront être dans deux PBL différentes si elles ont le même nom et les mêmes arguments).

Tandis qu'avec des userobjets hérités de l'objet transaction, il te sera plus facile de "jongler" entre les deux.
Ce n'est d'ailleurs pas un hasard si Sybase a repris ce principe avec ses PFC et toutes les méthodes de gestion transactionnelles et de BDD
of_commit, of_begin, of_distinctvalues,etc... implémentées au niveaux de descendants de l'objet transaction (Pour rappel, pfc_n_tr et ses descendants).

De plus, cela facilite la maintenance d'avoir tout de regroupé dans un même objet, plutôt que de multiplier les fonctions globales.

Ah, le mois de mai et ses trous dans l'emploi du temps... Je tarde à répondre, mais du coup j'aurai moins à dire

rincevent a écrit:

FMolinas, quitte à ne pouvoir avoir qu'une version de la fcontion today je ne pige pas l'intérêt de la définir comme fct° d'un objet ? (autant utiliser direct une fct Globale) et je comprends encore moins pourquoi tu parles d'hériter de l'objet transaction, peux tu m'expliquer ? (désolé si je suis un peu boulet :-) )

L'intérêt d'avoir des méthodes plutôt que des fonctions globales, c'est que tu peux hériter/surcharger les premières, mais pas les secondes (qui sont, mine de rien, des classes à elles toutes seules).
Quant à hériter de l'objet Transaction, foon a tout dit J'ajoute tout de même une fonctionnalité intéressante : les fonctions locales externes. Tu peux par ce moyen définir une fonction PB qui se trouve être un alias pour l'appel d'une procédure stockée de ta base. C'est un moyen pratique d'appeler une procédure stockée depuis un script PB sans être obligé de passer par les fonctionnalités barbares et exotiques du SQL dynamique... Jette un coup d'oeil à l'aide, à la rubrique "stored procedures, declaring".
Et il me revient aussi que l'appel d'une fonction globale est, il me semble, assez coûteux : à chaque appel, la machine virtuelle PB doit instancier la classe de ta fonction, puis nettoyer une fois la fonction finie. Ce n'est pas forcément rhédibitoire en termes de performances, mais quand même... Alors que normalement, tu as un objet (éventuellement hérité de) Transaction instancié en permanence.

rincevent a écrit:

merci pour vos réponses. c'est quand même assez emmerdant de ne pas être capable de faire en tant que Dev. ce que PB se permets (ie avoir une fonction qui renvoie un coup une date un coup une datetime) ça fout vraiment le boxon, ils pouvaitent pas faire une fonction today() et une todaynow() non ?

En fait, je soupçonne PB de n'avoir qu'une seule fonction qui renvoie un DateTime... automatiquement tronqué en date au besoin. C'est un peu limite quand même ce genre de pratique... En fait, le PowerScript ne travaille pas nativement sur le type DateTime, qui n'est fourni que pour assurer la communication avec les SGBD. Il gère les deux types Date et Time, mais quasiment pas leur combinaison... ce qui explique la désespérante pauvreté des fonctions de gestion date/heure

rincevent a écrit:

j'insite aussi sur l'intérêt de pouvoir remplacer de façon transparente les appels à today() comparé à simplement appeller une nouvelle fonction style gf_today() ce qui pose le problème de devoir faire attention en permanence à jamais utiliser today(), ce qui est vite arrivé, surtout quand beaucoup de consultants différents travaillent sur l'appli pour des courtes périodes. Autrement dit si je peux pas remplacer de façon transparente je sais d'office qu'un jour qqun va récup l'heure du PC au lieu de l'heure serveur.

Pas la peine d'insister, nous sommes d'accord sur le grand intérêt de la chose. La fourberie de Chrnico est magnifique, je la ressortirai un jour s'il n'a pas breveté le procédé