Présentation
Documentation
L'équipe
Sérialisation
 
Programmes
Objets
Libs Utilitaires
Libs Internes
   
 
Editeur
Syntaxes
Windows
Versions
   

SCR/AL1 - Evolutions récentes

5. Modifications apportées dans la version 4.46 (février 1999)

Bufferisation des ISAM

Position du problème

Dans le cadre des bases de données de type indexé séquentiel, la recherche d'un enregistrement est relativement rapide. Si on dispose d'un index de recherche et d'une valeur pour l'index, la recherche ne demande que quelques fractions de secondes et une ou deux lectures sur disque pour obtenir l'information.

Si on veut reproduire un comportement semblable pour une base de données relationnelle, on va devoir recourir à des requêtes SQL qui, avant d'effectuer l'opération de lecture proprement dite, vont nécessiter un travail considérable d'analyse:

Ces opérations - en particulier la troisième - peuvent être très pénalisantes par exemple dans le cas de MPAGE avec LPG contenant un ou plusieurs champs CODEISAM ou des impressions de listings avec des champs CODEISAM à calculer. Si un seul enregistrement est recherché (un produit par exemple, identifié par un code), la mécanique mise en place est lourde et sa répétition pour de nombreuses recherche est très lourde, donc lente.

Dans le cas du portage direct d'une application ISAM vers une application relationnelle, les pertes en traitement vont être considérables de par la méthode necessairement implémentée pour assurer la compatibilité.

Supposons par exemple la séquence ISAM suivante :

En SQL, on aura

La différence de temps d'exécution entre ces deux situations est importante et, dans le cas de traitement répétitifs, peut rendre pénibles les délais d'attentes.

Le fichier debug.win qui est optionnellement activé dans les applications SCR permet de se rendre compte des requêtes exécutées et, dans certains cas, des répétitions inutiles de requêtes SQL.

La bufferisation

Pour pallier ce problème, une solution simple et souvent efficace est de conserver dans l'application les derniers enregistrements lus et de les réutiliser s'ils sont à nouveau recherchés sans repasser par le serveur. On peut éviter de la sorte un grand nombre de requêtes inutiles et gagner par conséquent un temps considérable.

Deux paramètres permettent de gouverner le traitement des enregistrements bufferisés:

Le premier est évident : il indique combien d'enregistrement maximum seront bufferisés en vue d'une éventuelle exploitation ultérieure.

Le second permet de supprimer du buffer les enregistrements qui ont été lus depuis plus d'un certain temps. Si on considère par exemple que les codes produits ne sont jamais modifiés, on laissera cette valeur à 0, ce qui indique qu'un enregistrement lu reste valable pour toute la durée de vie du programme. Si par contre, un enregistrement client peut être modifié par un autre processus, on indiquera que la durée de vie est seulement de quelques secondes. Ces quelques secondes pourront faire gagner de nombreuses requêtes par exemple dans les affichages de MPAGE ou dans les listings, et ne seront en principe pas pénalisantes pour la fiabilité de l'application.

Implémentation dans SCR/AL1

La bufferisation est implémentée au niveau des ISAM, et pas des bases de données proprement dites. Par conséquent, elle fonctionne aussi bien pour CTREE que pour Oracle ou Informix.

La seule fonction qui profite de la bufferisation est IS_search(). C'est elle qui est aussi la plus lourde dans une base de données relationnelle et la plus souvent utilisée dans la plupart des applications.

Les autres fonctions sont adaptées pour que la gestion se fasse correctement. IS_open(), IS_close(), IS_next(), IS_prev(), IS_rewrite(), IS_delete() sont les principales fonctions modifiées pour traiter correctement la bufferisation.

Deux nouveaux mots-clés sont implémentés dans les ISAM :

Les mêmes mots-clés au niveau global permettent de fixer une valeur par défaut pour tous les ISAM qui suivent dans les sources.

        GLOBAL BUF_SIZE nn
GLOBAL BUF_SYNC nn

Resynchronisation

De nouvelles fonctions et variables sont introduites pour permettre de gérer la synchronisation des enregistrements bufferisés.

L'action BUF_SYNC exécute la fonction IS_resync_all().

Opération Reread

De nouvelles fonctions et variables sont introduites pour permettre de gérer plus efficacement les opérations de rewrite et de delete.

Pour s'assurer que l'enregistrement courant d'un ISAM n'a pas été modifié depuis sa lecture, les fonctions IS_rewrite() et IS_delete() relisent l'enregistrement avant l'opération de modification ou de destruction proprement dite. Dans de nombreux cas, cette opération est inutile: lorsqu'on balaie des enregistrements pour les modifier sans intervention d'un opérateur, le temps écoulé entre le read et le rewrite n'est que de quelques milli-secondes et un reread ne s'impose pas. Dans le cas des bases de données relationnelles, cette opération est coûteuse et inutile. La fonction reread n'étant pas implémentée, il faut effectuer un nouveau SELECT qui n'apporte rien de neuf par rapport à celui qui vient d'être effectué.

Pour éviter ce surcroît de travail, on peut utiliser les fonctions

qui ne vérifient pas que le record lu n'a pas été modifié depuis sa lecture.

La variable

        - int SCR_NO_REREAD

qui vaut 0 par défaut peut être fixée à 1 pour annuler les reread dans les fonctions IS_rewrite() et IS_delete() qui suivent.

Exploitation sous Unix

Sous Unix, la bufferisation ne prend pas en compte l'"age" de chaque enregistrement recheché. Par conséquent, dans la version actuelle, fixer un BUF_SYNC à une valeur non nulle n'a pas d'effet.

ISAM

Attention : IS_search(x, x, x, NULL) si la base de données concernée n'est pas CTREE. Sinon, la bufferisation ne peut avoir lieu. Pire, ce quatrième paramètre, lorsqu'il est non nul, indique une WHERE Clause. La méthode de passage des paramètres en C peut entraîner des plantages dans certains cas. Il est donc recommandé de faire un grep IS_search dans toutes les sources.

Nouvelles fonctions

Nouvelles variables

Programmes

SCR4_MKI

Nouveaux mot-clé dans REGISTER : MIME "mime-type". Cela permet d'associer une extension à un mime-type et ainsi de lancer automatiquement un programme de visualisation de fichier dans Netscape ou IE3-4.

Pour que cela soit opérationnel, il faut que le server interrogé envoie le mime-type du fichier concerné. Par exemple,

        REGISTER {
FILE iode
EXTENSION ".var"
MIME "application/x-iodevar"
CODE "IODE.VAR"
TITLE "IODE Variables"
OPEN "$maindir\\iode.exe %1"
PRINT "$maindir\\iode.exe -p %1"
ICON "$maindir\\iode.exe,7"
}

Lorsqu'un fichier .var est sélectionné dans le browser, le server doit envoyer un document de type "application/x-iodevar" pour que ce fichier soit visualisé automatiquement par le programme IODE.

D'autre part, les délais lors de l'installation des groupes de programmes sont supprimés.

Directory

On peut spécifier un nom de drive (m:) comme destination de l'installation. Avant, il fallait en plus un nom de répertoire.

MT v3.11

scr4wdb ou scr4w

Nouveaux paramètres:

scr4w_e

Lors de la génération des ressources Windows (scr4w_e), les champs de plus d'une ligne n'ont plus l'attribut AUTOHSCROLL de façon à ce que les lignes se scindent automatiquement lors de la saisie.

scr4_app

Correction d'une erreur dans la lecture des fichiers concaténés par scr4_app.

Windows NT

L'icône d'une application DOSW32 doit être définie dans la fonction WscrDOSUserInit() via la variable WSCR_ICON. Sous Windows 95 ou 98, la première icône définie dans l'exécutable est utilisée par défaut. Ce n'est pas le cas de Windows NT.

La désinstallation se fait correctement par les Fns WscrRegisterDelete*(). En NT, cette fonction ne marchait pas dans certains cas.

REREAD

Dans le cas où un ISAM contient une read_fn, le record lu risque d'être modifié par cette fonction. Par conséquent, aucune vérification (reread) n'est effectuée dans ce cas.

DOS

Copyright © 1998-2015 Jean-Marc Paul and Bernard PAUL - Envoyez vos remarques ou commentaires à bernard@xon.be