par David Robertson
La valeur "null" constitue un nouvel et puissant outil demanipulation
de dates en RPG
Depuis la V3R7, l'OS/400 accepte une nouvelle valeur pour les champs d'une base
de données : null. En vous offrant un moyen solide et élégant de traiter de futures
dates, cette valeur facilite l'utilisation pratique du type de donnée date. Dans
cet article, j'expose différentes raisons d'utiliser une date nulle, montre comment
définir des dates nulles et explique comment les traiter dans des fichiers logiques,
des DFU (Data File Utility), des requêtes et le langage RPG IV.
Dopez vos traitements de dates avec les champs nuls
Le concept de dates nulles n’est pas vraiment nouveau. Depuis toujours, nous rencontrons
des dates qui n’ont pas encore servi ou qui ne serviront peut-être jamais. Ainsi,
le fichier du personnel contient des champs dates de début et de fin d’emploi,
mais il est très rare que nous connaissions cette dernière au moment où nous ajoutons
cette personne au fichier. De même, certains fichiers clients contiennent des
champs de date qui ne serviront peut-être jamais, comme « Limite de crédit dépassée »
et « Date de notification ». Et, dans un fichier produits, certains enregistrements
possèdent un champ « Date de péremption » dont d’autres sont dépourvus.
Jadis, les programmeurs traitaient parfois de tels champs en leur attribuant une
valeur fictive, comme 31/12/99 (même s’ils regrettent amèrement ce choix à l’approche
du vrai 31/12/99 ! ! !). Ma stratégie préférée en matière de date nulle consistait
à entrer des zéros partout pour un champ de date facultatif (si (IF) une date
était différente de zéro, alors (THEN) c’était forcément une date valide). Facile
à coder, simple à comprendre, une date à zéro n’était rien d’autre qu’une date
nulle. De plus, il était facile d’imprimer des dates à zéro en RPG. Un code édition
Y produisait 0/00/00 pour de telles dates, et un mot d’édition » / / » produisait
une zone vierge, sans les barres obliques.
Mais, me direz-vous, si les dates à zéro fonctionnent et existent depuis des années,
à quoi sert cette nouvelle « date nulle » ? Et bien, c’est que nos anciens champs
« date » n’étaient pas vraiment des champs date, mais plutôt de simples champs zonés
ou packés dont nous savions qu’ils contenaient des dates ; ou qui, à tout le moins,
était supposés en contenir ! Un tel champ de date pouvait-il contenir, par exemple,
la valeur 063198 ? Bien sûr. La seule réserve étant les programmes à écrire pour
accéder au fichier et le fait que si notre contrôle de validité était laxiste
ou si quelqu’un se servait d’un utilitaire comme DFU pour entrer des données,
le champ pouvait contenir n’importe quoi. C’est pourquoi nous pouvions y placer
des zéros.
Avec des champs de type date, le système sait que les champs représentent plus
que de simples nombres. Ils ne peuvent contenir que des dates valides du 1er janvier
0001 au 31 décembre 9999. Même avec DFU ou avec la commande UPDDTA (Update Data),
il est impossible de placer une date erronée, contenant par exemple uniquement
des zéros (00/00/0000), dans un champ de type date, ce qui nous satisfait pleinement…
jusqu’à ce que nous arrivions aux dates qui n’existent pas encore réellement.
On pourrait utiliser une valeur spéciale comme 01/01/0001 ou 31/12/9999 dans de
telles situations, mais, sur le plan technique et esthétique, cette solution laisse
quelque peu à désirer. Faisons entrer en scène les dates nulles. Par définition,
null signifie absence de valeur, et donc il semble logique de l’utiliser pour
indiquer une date non encore connue.
Téléchargez cette ressource
Microsoft 365 : 5 erreurs de sécurité
A l’heure où les données des solutions Microsoft 365 sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités ? Découvrez le Top 5 des erreurs à ne pas commettre et les meilleures pratiques recommandées par les Experts DIB France.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Le spatial dans le viseur des cyberattaquants
- Connaître son client : exploiter les API des réseaux pour offrir des services personnalisés et sur mesure
- Architecte cloud : applications de chatbot & Azure OpenAI Service
- Le LLMjacking : quand les cyberattaques utilisent illicitement des comptes LLM
- Les identités des développeurs doivent être prises en compte !