fgstamp

Applications dBASE et an 2000

Face au défi du passage de l'an 2000, les entreprises qui exploitent des logiciels réalisés à l'aide de l'une des versions de dBASE sont sans aucun doute favorisées par rapport à leur concurrentes.

En effet, dBASE avait prévu l'essentiel pour parer au "bogue de l'an 2000" depuis ses premières versions du début des années 80. Pendant ce temps, les programmes en Cobol des mainframes, les RPG des minis et même des Excel et Access de ces dernières années jouaient les Tartufes.


Les fichiers de données

Dans les tables de données DBF, tout d'abord, dans les champs de type Date les données sont stockées depuis dBASE III+ sous le format AAAAMMJJ; c'est à dire l'année complète en quatre chiffres, le mois et le jour en deux chiffres chacun. La fourchette de dates prise en compte va de l'an 1 à 9999. Il n'y a donc aucun problème en ce qui concerne les dates au niveau des données stockées elles-mêmes, ce qui est déjà une excellente nouvelle.

Il y a cependant un bémol en ce qui concerne une information stockée dans l'en-tête des tables : la date de dernière modification de la table. Cette dernière est en effet stockée en binaire dans trois octets, dont un pour l'année. Nous aborderons plus en détail ce point plus loin, dont les effets dépendront du logiciel utilisé.

Enfin, les fichiers de stockage de variables mémoire (extension .MEM) conservent aussi les dates dans un format complet, siècle compris. Mais cela nous amène à parler du stockage et de la manipulation des dates en mémoire par dBASE.


Les calculs sur les dates

En interne, les différentes versions de dBASE proposent des commandes et fonctions permettant tant une arithmétique sur les dates, que la conversion bidirectionnelle entre ce format et le format chaîne de caractères. Il n'est pas dans notre propos ici d'aborder ces fonctionnalités connues et amplement documentées. Disons simplement que ces différentes fonctionnalités sont entièrement compatibles an 2000.

Nous donnerons tout de même les précisions suivantes.

Le stockage des dates en mémoire

A titre d'information, précisons tout d'abord que dBASE stocke les dates en mémoire sous la forme de nombres à virgule flottante représentant le nombre de jours écoulés depuis un jour zéro, correspondant à l'origine du calendrier Julien.

Il s'agit d'un système chronologique créé par Joseph Scaliger en 1582. Une date y est mesurée en comptant le nombre de jours écoulés à partir d'un jour zéro arbitraire : le 1er janvier 4713 avant notre ère, à midi (GMT). Par exemple, le 1er janvier 1980 en calendrier Julien est JD 2.444.240,0.

Les limites du calcul

Les points suivants sont à prendre en compte, bien que constituant des cas limites, sauf en ce qui concerne le dernier :


Les index

Selon la version de dBASE, le développeur et la logique de traitement concernés, une expression d'index impliquant des dates pourra prendre de nombreuses formes. Lorsque la clé d'index correspond à un champ de type Date, il n'y a probablement rien à faire.

Cependant, lorsque la date est en tout ou partie membre d'une clé complexe, des fonctions dBASE sont employées pour constituer une chaîne de caractères. Il sera parfois nécessaire d'envisager la modification d'une clé qui ne tiendrait pas compte du siècle ou qui incorporerait une constante. Cela risque d'être compliqué en cas d'absence de documentation technique et de dossier d'analyse. Il sera alors bon de prévoir le temps nécessaire pour les tests en avançant par tâtonnement.


Les écrans

Il reste donc essentiellement la question des zones de type Date sur les écrans. Il y a là deux considérations à prendre en compte: la dimension de la zone de saisie, d'une part, et le comportement du logiciel en cas de saisie de deux chiffres seulement pour l'année, d'autre part.

Les zones de saisie

Commençons par le cas le plus simple, celui de la dimension de la zone de saisie. Dans toutes les versions de dBASE, le format d'affichage d'une zone de saisie de date dépend essentiellement d'une commande d'environnement : si SET CENTURY est à ON, la date s'affiche par défaut avec quatre positions pour l'année. Si cette commande est à OFF, la zone de saisie d'une date ne présentera que deux chiffres pour l'année.

Remarquons donc au passage que, dans l'absolu, il suffirait d'ajouter cette commande en début de traitement pour résoudre une grande partie du problème d'affichage et de saisie des dates. Dans la pratique, il y a d'autres éléments à prendre en compte.

Tout d'abord, le format d'affichage peut également être contrôlé par une clause de masquage (picture). Si une telle clause limite l'affichage de l'année à deux positions numériques pour l'année d'une zone de saisie donnée, le changement de la commande d'environnement globale n'y changera rien.

Ensuite, en supposant qu'il n'y ait pas de clause limitative dans le code des programmes, l'extension de la largeur d'une zone de saisie peut empiéter sur l'affichage d'une information voisine à l'écran. Il peut donc être tout de même nécessaire de revoir les formats d'écran.

Enfin, la logique de validation et de traitement après saisie peut également entraîner des effets pervers non prévus par le développeur d'origine.

Saisie sur zones à deux chiffres

Mais si nous faisons passer la zone de saisie de deux à quatre chiffres pour l'année, cela veut-il dire que l'utilisateur sera obligé de saisir l'ensemble des quatre chiffres à partir de l'an 2000 ?

Nous rejoignons ici le second cas à considérer. Il s'agit bien entendu des zones pour lesquelles n'ont été prévues que deux chiffres pour l'année. Rappelons cependant qu'il ne s'agit que d'une question d'affichage, puisque les données sont traitées et stockées avec quatre chiffres pour l'année. Le problème peut donc être illustré sous la forme de la question suivante : Lorsque l'utilisateur saisit l'année de la date sous la forme '00', que se passe-t-il ?

La réponse dépend de la version de dBASE. Disons tout d'abord que pour toutes les versions DOS, ainsi que pour les versions 5.0 et 5.5 sous Windows, l'année est complétée automatiquement Par l'ajout de 1900 aux deux chiffres saisis.

Les versions récentes

Pour ce qui est des versions 5.6 et 7.x, le comportement dépend d'une nouvelle commande d'environnement: SET EPOCH TO. Cette commande permet de fixer le seuil frontière automatique pour l'affectation de l'année saisie au vingtième ou au vingt-et-unième siècle. Par exemple, en supposant un seuil fixé à 30, toutes les valeurs d'années saisies entre 00 et 29 seront complétées à 2000, alors que les valeurs entre 30 et 99 seront complétées à 1900.

Ce mécanisme de "fenêtrage" permet d'adapter le comportement automatique de complément de la date à la nature du logiciel et à l'activité particulière de l'utilisateur, sans complexité supplémentaire de programmation.

Soulignons que ce comportement est actif même si la zone de saisie comprend quatre chiffres pour la date. C'est à dire que l'utilisateur peut continuer à ne saisir que deux chiffres, les deux précédents étant complétés automatiquement dès que l'utilisateur valide ou quitte la zone de saisie.

La technique du fenêtrage doit être cependant utilisée avec discernement. Il existe en effet des cas pour lesquels elle peut donner des résultats erronés. Ce sera le cas, par exemple, en cas de saisie de dates de naissance très anciennes, ou d'applications en relations avec des travaux historiques. Il sera dans certains cas plus simple de combiner SET EPOCH avec SET CENTURY, de façon à fournir une vérification visuelle des anomalies, l'année s'affichant alors en quatre chiffres même si elle est saisie en deux chiffres seulement.

Il reste donc à régler la question des versions antérieures à la 5.6. Il faut dans ce cas différencier la situation des logiciels réalisés sous DOS et sous Windows.

dBASE sous DOS

Avec dBASE IV et dBASE 5 pour DOS, il est possible soit de se contenter de procéder à une modification des formats d'écran après avoir mis SET CENTURY à ON pour agrandir les zones de saisie, soit d'ajouter de la logique de traitement dans les clauses de validation des champs date, ou encore d'utiliser les deux méthodes.

Dans le premier cas, l'importance de l'effort dépendra bien entendu du nombre de zones de dates et du nombre d'écrans, mais surtout de l'encombrement desdits écrans.

Pour le second cas, il est possible d'ajouter une procédure qui prenne en compte la logique du complément du millénaire pour une date saisie à deux chiffres. Cette procédure devra être alors invoquée dans les clauses de validation (VALID) de toutes les zones de saisies impliquant des dates. Elle se substituera alors au complément automatique à 1900 effectué par défaut.

Pour les programmes fonctionnant encore sous dBASE III Plus, la validation ne peut pas être effectuée zone par zone. La logique particulière de chaque gestion d'écran dépendant plus du développeur, il sera nécessaire de procéder au cas par cas. Cela implique donc qu'il sera peut-être préférable de faire migrer l'application vers dBASE 5 pour DOS ou Visual dBASE pour faciliter la mise en place d'une solution.

Version 5.0 et 5.5 sous Windows

Qu'en est-il pour les logiciels réalisés sous les versions 5.0 et 5.5 sous Windows à présent ?

Il peut être envisagé de les faire migrer vers la version 5.6. Il s'agit d'une mise à jour gratuite si vous possédez la version 5.5. Il s'agira par contre d'un achat aux conditions de migration depuis une version précédente dans le cas de la version 5.0 (dBASE pour Windows).

Il convient cependant dans ce cas de prévoir un peu de temps pour effectuer les modifications et les test nécessaires non seulement pour l'an 2000, mais également pour le changement de version du logiciel. En effet, la compatibilité est excellente, mais la version 5.6 tolère moins certains comportements laxistes en programmation. En contrepartie, elle apporte la correction d'un certain nombre de problèmes, une bonne stabilité et la prise en compte du complément automatique du millénaire, comme nous l'avons déjà signalé plus haut.


Les autres formats de stockage de données

Nous avons abordé le cas des données stockées dans des tables DBF. Au cas où la source de données est dans un autre format, il conviendra alors de distinguer d'une part le format de stockage des données dans la base de données concernée, et d'autre part le comportement interne de dBASE.

Ce dernier ne change pas par rapport à ce que nous avons dit en ce qui concerne la logique interne de calcul sur les données de type Date. Cela, dans la mesure où les données sont prises en compte en type Date dans dBASE. En ce qui concerne le format de stockage propre à la base de données concernée, il conviendra de se reporter aux spécifications concernées.

Par exemple, InterBase est en mesure de stocker et traiter des dates allant de l'an 100 à l'an 5941. Par ailleurs, si la date est fournie avec deux chiffres pour l'année seulement, InterBase choisira la date la plus proche dans une fourchette de cinquante ans. Par exemple, '48' sera interprété comme '1948', alors que '47' sera interprété comme '2047'.

A titre d'information, précisons que la date est stockée sur disque par InterBase sous forme d'une structure de deux entiers de 32-bit. Le premier d'entre eux est un entier signé représentant le nombre de jours depuis le 17/11/1858. Il s'agit de la date pivot traditionnellement utilisée dans les systèmes DEC.

Voyons à présent plus en détail certains cas particuliers qu'il convient de prendre en compte.


Le cas du 29 février 2000

Il reste un petit problème qui a été insuffisamment pris en compte en version 5.6 : il s'agit d'un cas limite de "fausse" erreur de validation pour la saisie de la date dans un objet EntryField pour le 29 février 2000.

Si la saisie de cette date est effectuée sous la forme 29/02/00, le logiciel affichera en effet un message d'erreur. Ce ne sera par contre pas le cas si la saisie est effectuée sous la forme 29/02/2000. Cela sera le cas même si SET EPOCH TO est correctement positionné.

En fait, il semble que le contrôle sur une date saisie avec deux chiffres pour l'année soit effectué par Visual dBASE par une première recherche sur l'année complétée à 1900. Puis, la nouvelle logique de complément selon le paramètre défini par SET EPOCH est appliquée ensuite. L'inconvénient est qu'il n'y a pas de 29 février en 1900. Par contre, si la date est saisie en quatre chiffres, elle passe le contrôle sans erreur.

Si les zones de saisie des dates à l'écran ne peuvent pas être passées en format à quatre chiffres pour l'année pour une raison particulière, il conviendra alors d'intégrer le code nécessaire pour éviter ce message d'erreur dans la méthode Valid des objets de saisie, ou dans un événement exécutant une méthode appropriée en cas d'erreur.

Il s'agit cependant d'un bogue que l'on peut qualifier de bénin, puisqu'il ne concerne que l'affichage d'un message d'erreur inadéquat, alors que le traitement de la date n'est pas en cause.


Le cas de la date de dernière mise à jour

Il s'agit là d'une caractéristique curieuse que certains veulent considérer comme un défaut de conception.

Comme nous l'avons dit plus haut, l'année de cette date est stockée dans un octet de l'en-tête du fichier DBF. Ce nombre binaire peut être considéré également comme étant en format hexadécimal à deux chiffres. La fourchette théorique de valeurs possible va donc de x00 à xFF, c'est à dire de 0 à 255 en décimal. Ce nombre représente le déplacement en années depuis 1900.

La question est donc la suivante : que se passe-t-il lors du passage du 31/12/1999 au 01/01/2000 au niveau du système d'exploitation ?

De dBASE IV à Visual dBASE

Dans l'une quelconque de ces versions de dBASE, rien de particulier avant... 2155 !

En effet, s'agissant d'un nombre binaire, il continuera tout simplement à être incrémenté de 1 et ajouté à 1900, donc, correctement jusqu'en 2155 (1900 + 255).

Le danger pourrait par contre venir de l'extérieur. En effet, si vous échangez des fichiers de données DBF avec d'autres logiciels, certains d'entre eux ne gèrent pas cette date de la même façon que dBASE et peuvent la remettre à zéro pour l'an 2000. Cela aura-t-il ou pas une influence sur votre application ?

Cela dépend de l'utilisation que vous faites de cette information. Pour s'en assurer, l'on pourra rechercher dans ce cas non seulement la présence de la fonction LUPDATE() dans le code source, mais également de la fonction LKSYS(). Il sera éventuellement nécessaire d'ajouter un contrôle de la date de dernière mise à jour des fichiers DBF importés avant utilisation.

dBASE III+

Contrairement aux versions suivantes de dBASE, cette version n'incrémente pas l'octet de l'année de mise à jour de la table DBF au-delà de 99 (x63). Pour l'an 2000, la valeur de l'octet repasse donc à x00.

Cela ne pose pas de problème particulier à une application dBASE III+, qui continuera à utiliser normalement ses tables. Cela, cependant, à condition que les tables ne proviennent pas d'autres logiciels ne respectant pas le même processus d'incrémentation de l'octet de l'année.

Notamment, si la table est créée ou mise à jour dans dBASE IV ou dans Excel, l'octet de l'année sera à x64 pour l'an 2000. Une telle table ne sera pas ouverte par dBASE III+.


Autres cas

Il reste bien entendu un certain nombre de cas particuliers. Ils sont à prendre en compte ou pas selon le cas et selon l'application. Citons notamment l'importation de données à partir d'autres formats de données. Même si dBASE traite les dates de manière fiable en interne, il conviendra de s'assurer que les dates qui sont transférées depuis l'autre système sont dans le bon format. C'est à dire que l'année continuera à être fiable dans les fichiers importés après l'an 1999.

La relation avec le système

Le logiciel d'application dépend des couches système sur lesquelles il repose pour des opérations de base. Par exemple, la date système renvoyée par la fonction DATE() est retournée par dBASE après requête au système. Si ce dernier reçoit une information erronée du BIOS, ou bien si l'horloge RTC n'est pas capable de passer le cap de minuit sans effets de bords, l'information renvoyée ne pourra pas être correcte. Ce cas d'espèce est surtout à considérer dans le cas des systèmes tournant en continu 24h sur 24, évidemment. Dans ce cas, il convient de s'assurer du comportement de l'horloge RTC et du BIOS de l'ordinateur avec un soin particulier.

Et les autres dates...

Bien entendu, dans cette étude l'on considère que les fonctionnalités adéquates ont été employées et que le type de données interne "Date" est employé pour le stockage et la manipulation des données concernant des dates.

Si le développeur a utilisé des champs de type Caractère ou Numérique, contournant de ce fait les mécanismes internes, la situation est sensiblement différente. Il conviendrait notamment dans ce cas de prévoir dans le plan d'action la recherche de chaînes de caractères ou constantes numériques comme "19" dans les programmes source.

Par ailleurs, SET EPOCH n'influence pas que la saisie des dates par l'utilisateur. Selon l'application, s'il y a conversion de chaînes de caractères à 6 chiffres en dates, il faudra se rappeler que la fonction CTOD() respecte la fenêtre de date introduite par SET EPOCH. Cela peut provoquer des résultats inattendus.

De même, selon les nécessités des règles de gestion de l'entreprise, ou bien de l'échange de données avec d'autres systèmes, on peut également trouver des éléments de dates dans des codes produits ou des noms de fichiers, par exemple.

S'il y a échange de données avec d'autres environnements, l'on pourra éventuellement se reporter aux études plus générales concernant l'audit de fichiers et programmes dans des environnements minis et grands systèmes, par exemple.

Enfin, si des modules binaires externes sont utilisés dans l'application (LOAD/CALL), il conviendra de s'assurer qu'ils n'effectuent pas de traitements non compatibles an 2000 sur les dates. Le cas échéant, il faudra les modifier, les remplacer, ou faire migrer l'application vers une version plus récente pour pouvoir effectuer le traitement externe en dBASE, ou bien à l'aide d'un composant (VBX/ActiveX) ou d'un programme externe piloté (DDE/OLE) ou commandé par une API (EXTERN).


Les tests et les surprises

Il ne faut pas négliger de prévoir suffisamment de temps et de ressources pour les tests. En effet, la modification d'une application auparavant stable peut avoir des conséquences imprévisibles. L'ajout de nouvelles fonctions peut achever de saturer la zone des variables mémoire ou la table des symboles notamment. Cela, sans parler de révisions fondamentales pouvant être nécessaires sur des écrans déjà saturés de zones de saisie.


L'an 2000 et l'Euro

Si l'application donne satisfaction et que les correctifs à appliquer pour la mise en conformité an 2000 sont faibles ou d'une ampleur raisonnable, il est probable qu'il sera nettement moins coûteux d'y procéder que d'effectuer un nouveau développement, ou encore d'envisager le passage à un progiciel ou un ERP, éventuellement complété par des modules personnalisés.

Il est de toute façon certain qu'étant donné le délai relativement court avant l'échéance, ainsi que l'impossibilité de la reculer, il faut être extrêmement prudent avant de s'aventurer dans un développement ambitieux, impliquant par exemple un changement de plate-forme ou un développement entièrement nouveau.

Quoi qu'il en soit, il faut également étudier l'incidence éventuelle de l'introduction de l'Euro par la même occasion. Cela, d'une part parce que les échéances seront selon le cas proches ou confondues, et d'autre part, parce que certaines techniques sont similaires et peuvent avoir à être implantées dans les mêmes programmes.

François Ghoche
www.fghoche.com


[ Début ] [ Page précédente ] [Accueil site ]

© copyright 1995-1998, J. François Ghoche - Reproduction intégrale autorisée exclusivement à titre entièrement gratuit. Toute reproduction partielle (même gratuite), et toute reproduction payante de quelque manière, sont soumises à autorisation préalable. Tous droits réservés
Toutes informations sont fournies à titre indicatif. Il appartient au lecteur d'étudier sous sa propre responsabilité leur possible application à son cas particulier. Aucune garantie explicite ou implicite n'est fournie.

Tél: +33 (0) 139 440 301 - Fax: +33 (0) 139 440 331 - Mail: atonfghoche.com - Web: www.fghoche.com
Poste: 33 allée des Genêts - 78280 Guyancourt - France