Quand on utilise des types de données date, il faut que les formats de date soient compatibles entre les UDF et leurs applications hôtes. Si, par exemple, un environnement SQL utilisant le format de date *ISO invoque une UDF conçue pour traiter des dates *MJA, on risque des problèmes parce
Derniers écueils à éviter
qu’une date *ISO peut contenir un plus grand
intervalle de valeurs de date qu’une date *MJA.
Comme deux UDF peuvent partager le même nom mais être conçues pour accepter des
nombres et des types de paramètres différents, l’identificateur unique pour une
UDF est collection, nom, nombre de paramètres et types de paramètres. Ainsi, l’écriture
d’une fonction Translate personnalisée pouvant accepter des types de données VarChar
ou Char, demande deux définitions de fonctions avec le même nom mais des types
de paramètres différents.
Si le type d’un argument transmis à une UDF n’est pas cohérent avec le type de
paramètre correspondant, le type de l’argument doit être transférable au type
du paramètre (un transfert est une conversion d’un type de données en un autre).
Si les types de données ne correspondent pas et ne sont pas « transférable », on
recevra une erreur « nom-fonction NOT FOUND IN *LIBL ». Par exemple, le paramètre
quantité de temps CvtHours a un type de données Decimal(11,2). Il est acceptable
de transmettre un type de paramètre de Decimal(9,2) à CvtHours, parce qu’on peut
le mettre sous la forme Decimal(11,2) attendue. Mais un type de paramètre Decimal
(13,5) serait rejeté parce qu’on ne peut pas le promouvoir en Decimal (11,2).
Dans ce cas, SQL signalerait qu’il n’a pas pu trouver la fonction CvtHours. Par
ce message, SQL indique en fait qu’il ne peut pas trouver une fonction CvtHours
avec une liste de paramètres compatible.
On utilise l’instruction SQL Set Path pour définir la liste de collection (bibliothèque)
que SQL utilisera pour rechercher des UDF quand on compile un programme avec SQL
imbriqué ou qu’on exécute un script SQL. Par exemple, si on définit les UDF en
deux collections appelées UDFLIB1 et UDFLIB2, la syntaxe est Set Path = UDFLIB1,
UDFLIB2. Notons que le SQL Path indique où l’UDF a été créée (c’est-à -dire, la
collection explicite ou implicite utilisée sur l’instruction Create Function)
et non où l’objet de programme externe existe. Pour plus d’informations sur le
SQL Path, voir l’article « The Definitive Guide to SQL/400 Naming », NEWS/400, août
2000.
Enfin, il existe des limites pour les durées d’exécution d’une fonction, car SQL
fera un « time out » si l’exécution d’une UDF dure plus de 30 secondes. Pour savoir
comment augmenter cette valeur de time-out par défaut, voir l’article « L’optimiseur
de performances consolide les options de requête », NEWSMAGAZINE, mars 2000.
Téléchargez cette ressource
Guide de Threat Intelligence contextuelle
Ce guide facilitera l’adoption d’une Threat Intelligence - renseignement sur les cybermenaces, cyberintelligence - adaptée au "contexte", il fournit des indicateurs de performance clés (KPI) pour progresser d' une posture défensive vers une approche centrée sur l’anticipation stratégique
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- ADI, l’infrastructure de données de Scality pensée pour l’ère de l’IA et de la souveraineté
- Les coûts cachés des merge requests générées par l’IA
- WatchGuard lance Rai, une IA agentique taillée pour les MSP
- Mythos révèle les limites d’un Zero Trust centré sur le réseau
Articles les + lus
Analyse Patch Tuesday Mai 2026
Les coûts cachés des merge requests générées par l’IA
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Avril 2026
À la une de la chaîne Tech
- Analyse Patch Tuesday Mai 2026
- Les coûts cachés des merge requests générées par l’IA
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Avril 2026
