> Tech > Derniers écueils à  éviter

Derniers écueils à  éviter

Tech - Par iTPro - Publié le 24 juin 2010
email

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 gratuitement cette ressource

Comment sécuriser la Digital Workplace ?

Comment sécuriser la Digital Workplace ?

Avec le recours généralisé au télétravail, les entreprises ont ouvert davantage leur SI. En dépit des précautions prises, elles ont mécaniquement élargi leur surface d’exposition aux risques. Découvrez 5 axes à ne pas négliger dans ce Top 5 Sécurité du Télétravail.

Tech - Par iTPro - Publié le 24 juin 2010