DESCRIPTIF DES CORRECTIONS
Entrepôt de données Version 1.00 - Corrections 1 à 35
| ORTHOGRAPHE : SCENARII DEVIENT SCENARIOS | Correction N° 13 du 12/05/10 |
Le pluriel du mot scénario était incorrect. Tous les scénarii ont été remplacés par scénarios.
| PROBLEME DE MISE A JOUR | Correction N° 14 du 12/05/10 |
LDETLFB peut désormais se mettre à jour automatiquement. Un problème empéchait la copie de la mise à jour de se lancer.
| AMELIORATION DE LA GESTION DES HISTORIQUES ET DES MISES A JOURS + CORRECTIONS DIVERSES | Correction N° 15 du 31/05/10 |
La gestion des historiques a été améliorées :
- Le message indiquant le démarrage et la fermeture de l'application lors d'une mise à jour n'est plus affiché.
- Chaque message est désormais rattaché à un lancement unique de l'application. On peut ainsi afficher les messages triés en fonction de l'heure ou triés en fonction de l'instance de l'application.
Au niveau de la mise à jour, les disques réseaux sont connectés au début de l'application si l'application est exécutée par une tâche planifiée.
Diverses corrections ont été apportées :
- Il est désormais possible d'utiliser la molette sur le champ de source même s'il est grisé. Il suffit de survoler le champ et d'activer la molette.
- Le bouton permettant de choisir le fichier Firebird ne se grisait pas dans la fenêtre des familles de connexions cible.
| OPTIMISATION DES PERFORMANCES | Correction N° 16 du 07/07/10 |
Un travail d'optimisation des performance a été mené. Il a conduit à diviser par deux en moyenne le temps de chargement d'une table de l'entrepôt.
Plusieurs optimisations de code ont été faites, mais les 2 principales sont :
1) on fait un Commit tous les 100 ordres Insert seulement, et non pas après chaque Insert. Cela diminue grandement le nombre d'appels à DLL Firebird. Des tests ont été fait pour augementer plus encore le nombre d'enregistrements entre 2 Commit, mais cela n'a plus guère d'incidence.
2) l'ordre Insert est désormais construit sans la liste des champs. On ne met que la liste des valeurs à insérer, sachant que comme cette liste de valeur correspond exactement à la liste de tous les champs de la table, la liste des champs est inutile.
| PB CONNEXION SUR ANALYSE HF14 AVEC INDEX FULL TEXT | Correction N° 17 du 06/09/10 |
Lors de l'ouverture d'une connexion faisant référence à une analyse HyperFile 14 ou plus (sachant que LDETLFB V1.00 N16 est développé en Windev 12), si l'un des fichiers de l'analyse comportait un index "full text", cela provoquait une exception, et l'application LDETLFB se fermait.
Avec cette correction N° 17, l'exception est contrôlée ; un message d'erreur informe du fichier concerné par l'exception.
On peut ainsi "ouvrir" l'analyse, mais le ou les fichiers signalés en exception ne seront pas utilisables par LDETLFB.
| GESTION DES INDEX FULL TEXT | Correction N° 18 du 08/09/10 |
Suite à la correction 17, on peut désormais utiliser des fichiers possédant un index full text.
L'application est désormais développée en Windev 14, d'où la mise à disposition des dll en version 14.
| FICHIER D'INFORMATION SUR LES DERNIERES MISES A JOUR DE L'ENTREPOT DE DONNEES | Correction N° 19 du 24/09/10 |
Un nouveau fichier ENTREPOT a été créé au niveau de la base firebird. Ce fichier contient les dates et heures de dernières création et modification d'une table. Le dernier modèle et le nombre d'enregistrement sont aussi enregistrés.
| GESTION DES CLES PRIMAIRES ET SECONDAIRES AINSI QUE L'ACTIVATION ET LA DESACTIVATION DES CHAMPS | Correction N° 20 du 01/10/10 |
Clés primaire et secondaires
Afin d'améliorer les performances dans LDVision, il est désormais possible d'indiquer les rubriques clés. Pour ces clés, LDETLFB va créer un index dans la base de données Firebird. Un modèle accepte une clé primaire et jusqu'à 5 clés secondaires.
Seul un champ source qui ne peut pas renvoyer la valeur Null peut être utilisé comme clé primaire. Il faut veiller aussi à ce que ce champ ne génère pas de doublon (une clé primaire est forcément unique). Enfin, afin de se protéger des doublons, la clé primaire n'est pas obligatoire.
Désactivation des champs
Il est désormais possible de paramétrer une rubrique et de la désactiver. Une rubrique désactivée n'est pas utilisée par le modèle, mais son paramétrage n'est pas supprimé.
Désactivation dynamique des champs
Les champs qui sont renommés par une fonction lors de l'exécution du modèle peuvent être désactivés si cette fonction renvoit une chaine vide. Si un tel champ était utilisé en tant que clé secondaire, cette clé ne sera pas créée.
Connexion
Le fait de réouvrir une connexion alors qu'elle n'a pas été fermé a pour conséquence de fermer tous les fichiers. Désormais, si une connexion est déjà ouverte, elle n'est pas réouverte et les fichiers restent toujours accessibles.
Requête d'épuration
Il n'était pas possible de valider un modèle définissant une requête d'épuration. Le programme indiquait que le fichier cible n'était pas connu.
| TRANSFORMATION DES CLES PRIMAIRES EN CLES SECONDAIRES - MESSAGE OUI / NON LORS DE L'ANNULATION D'UN TRAITEMENT | Correction N° 21 du 19/10/10 |
Transformation des clés primaires en clés secondaires
Depuis le correctif 20, les clés primaires sont gérées par LDETLFB. Une clé primaire est obligatoirement unique. Jusqu'à présent, cette clé n'était pas utilisée et le problème des doublons ne se posaient pas. Afin de corriger ce problème, toutes les clés primaires sont transformées en clé secondaire. Cette transformation ne s'effectue qu'une seule fois par modèle. Cette modification est notée par un n° de version fixé à 2 dans le fichier du modèle.
Message Oui / Non lors de l'annulation d'un traitement
Lorsqu'on annule l'exécution d'un scénario ou d'un modèle, on affiche désormais un message Oui/Non de confirmation.
| PROBLEME DE CLE PRIMAIRE SUR LA TABLE ENTREPOT ET MEILLEUR GESTION DE LA FENETRE D'ANNULATION | Correction N° 22 du 22/10/10 |
Problème de clé primaire sur la table ENTREPOT
La création de la table ENTREPOT (voir correctif 19) ne fonctionnait pas avec la nouvelle gestion des clés primaires et secondaires. Il affichait tout le temps un message d'erreur indiquant que le mot nom n'était pas valide.
Meilleure gestion de la fenêtre d'annulation
En cas d'erreur, cette fenêtre ne se fermait pas. Il fallait redémarrer l'application pour s'en débarraser.
| CORRECTION DE DIVERS PROBLEME D'EXECUTION | Correction N° 23 du 27/10/10 |
Divers problèmes pouvaient être rencontrés dans l'utilisation de LDETLFB :
- Problème de compilation qui faisait que les index ne pouvaient pas être créés.
- Probleme de version de firebird qui empechait de créer la table ENTREPOT. La clé primaire sur cette table a été supprimée.
| MISE A DISPOSITION SUR NOUVEAU DVD | Correction N° 24 du 29/09/11 |
Pour mettre à disposition LDETLFB sur le nouveau DVD des logiciels LD, une version au niveau 24 a été générée (fonctionnellement identique au niveau 23).
| CORRECTION ERREUR SYSTEME DANS CONSTRUCTEUR DE TABLEFIREBIRD | Correction N° 25 du 22/02/12 |
On rencontrait parfois, de façon aléatoire, une erreur lors de l'exécution d'un scénario en mode automatique (soit lancé par un raccourci avec en ligne de commande le nom du scénarion à exécuter, soit directement dans une tâche planifiée).
L'erreur rencontrée était :
Code de l'erreur : 0
Code de l'erreur système : 0
Elément concerné : TableFirebird.Constructeur
Traitement en cours : Constructeur de la classe TableFirebird
N° de ligne : 0
Fonction W-Langage :
Infos complémentaires :
Message complet :
Message système :
------
Dump de l'erreur de module inconnu.
...
- Infos attachées :
EIT_PILEWL :
Constructeur de la classe TableFirebird (TableFirebird.Constructeur), ligne 0
Constructeur de la classe Modele (Modele.Constructeur), ligne 0
Procédure locale xExécuterModèleDepuisScénario (ModeleMaj.PROCEDURE.xExécuterModèleDepuisScénario), ligne 2
Procédure locale xExécuterScénario (ModeleMaj.PROCEDURE.xExécuterScénario), ligne 20
Pour corriger cela, 2 choses qui à priori n'ont rien à voir, ont été entreprises :
1) la procédure de connexion des disques réseau a été aménagée. Désormais, pour chaque disque réseau à connecter, elle vérifie si la connexion n'est pas déjà active. De plus, il y avait une erreur qui faisait que le système tentait de connecter 2 disques réseau correspondant au nom d'utilisateur et au mot de passe.
2) dans la classe Modèle, dans le code de déclaration de cette classe, on définit un objet de type TableFirebird. Cette définition a été rendue dynamique, avec ajout de l'allocation de l'objet au tout début du constructeur de la classe Modèle
Avec ces 2 corrections, l'erreur semble (je dis bien "semble", car comme elle est aléatoire, il est difficile d'être totalement affirmatif) avoir disparue.
| MODIF MODELE : MODIF CODE SOURCE D'UNE RUBRIQUE LA DESACTIVE | Correction N° 26 du 22/02/12 |
En modification d'un modèle, lorsqu'on modifiait le code source d'une rubrique en passant par la fenêtre de modification d'un champ calculé, cela avait pour effet de la désactiver. Il fallait ensuite la réactiver, en cliquant dans la dernière colonne de la table, sur la ligne correspondant à cette rubrique.
| PROBLEME NOMMAGE RUBRIQUE AVEC EASYCOM | Correction N° 27 du 16/04/12 |
Il y avait un souci avec Easycom lors de la modification d'un modèle. Quand LDETLFB recherche un modèle, il tente d'aligner la liste des rubriques du fichier ou de la requête source avec la liste des champs configurés dans le modèle.
Or, lorsque le modèle est basé sur une requête, et que cette requête est exécutée au travers de Easycom, les noms des rubriques sont retournés non pas dans la casse d'origine, mais avec la première lettre du nom en majuscule, et le reste du nom en minuscule. Du coup, LDETLFB n'arrivait pas à remettre en regard ces rubriques sources avec les champs définis dans le modèle.
Pour éviter cela, cette étape d'alignement des rubriques sources avec les champs du modèle se fait désormais sans tenir compte de la casse utilisée pour les noms de rubriques.
| MEILLEURE GESTION DES DISQUES RESEAUX EN MODE AUTOMATIQUE | Correction N° 28 du 04/10/12 |
Lorsque LDETLFB est appelé en mode automatique pour exécuter un modèle ou un scénario, la première chose qu'il fait est de connecter les disques réseaux ayant été configurés (visibles dans le fichier LDEParam.ini). Et cela même avant d'avoir exécuter les procédures initialisant toute la gestion des erreurs, ce qui est normal, les fichiers log dans lesquels on trace les erreurs étant souvent enregistrés eux aussi sur un disque réseau.
Le problème était que lors de la connexion des disques réseau, s'il y avait la moindre erreur, on se contentait d'afficher une erreur et d'attendre une réponse. Or, si l'exécution se fait dans une tâche planifiée, et qu'aucune session Windows n'est ouverte, la fenêtre d'erreur ne s'affichait nulle part et le programme restait donc bloqué sur cette erreur.
Désormais, en cas d'erreur lors de la connexion réseau, le système tente de "tracer" l'erreur de façon classique, dans l'historique d'une part, dans un fichier .log d'autre part, comme lors d'une exception. Cela va fonctionner le répertoire des données (celui où l'on trouve le sous-répertoire Historique) n'est pas sur un disque réseau, ou que ce disque réseau a pu être "monté" avant l'erreur de connexion que l'on cherche à tracer. Si le répertoire en question n'est pas acceible, le système enregistre l'erreur dans un fichier .log placé dans le même répertoire que le fichier d'initialisation utilisé au lancement (et donc en principe dans le répertoire des programmes).
Dans tous les cas d'erreur de connexion d'un disque réseau, l'application LDETLFB est ensuite fermée. Ainsi, on ne conserve pas un processus ouvert éternellement.
| AFFICHAGE HISTORIQUE - FONCTIONNEMENT INCERTAIN DU SPINBUTTON SUR DATE | Correction N° 29 du 04/10/12 |
Le bouton permettant de faire avancer ou reculer la date d'un jour, dans la fenêtre d'affichage de l'historique, avait un fonctionnement un peu incertain. Parfois, quand on était sur une journée sans historique, il n'avait plus aucun effet.
| PROBLEME AVEC FICHIER NEGOCEV5 NE POUVANT ETRE OUVERT | Correction N° 30 du 12/06/13 |
Suite à la mise en place de la version 5 de LDNégoce, on a constaté que certains fichiers modifiés en version 5 de LDNégoce (ACHBUR et VTEBUR) ne pouvaient être ouverts par LDETLFB. Il semble que cela soit dû à une fonctionnalité HF (FH 18 pour LDNégoce V5) non supportée par LDETLFB qui est en Windev 14, masi sans qu'on sache précisément laquelle (les fichiers ACHBUR et VTEBUR ne comportent pas de type de donnée ou de fonctionnalité particulière).
Dans l'attente d'une future migration de LDETLFB en Windev 18, on a contourné le problème : l'erreur 70313 signalée dans ce cas de figure n'est plus affichée à l'écran, ce qui évite de bloquer LDETLFB, que ce soit lors de la modification ou l'exécution d'un modèle. Les fichiers concernés (ACHBUR et VTEBUR) n'apparaissent donc plus dans la liste des fichiers exploitables par LDETLFB sur une connexion LDNégoce V5, mais aucune erreur n'est signalée.
| TOUTES PETITES OPTIMISATIONS PERFORMANCES | Correction N° 31 du 31/10/13 |
Différentes tentatives ont été menés pour optimiser les performances, sans grand résultat malheureusement.
Au final, seules 2 choses ont été conservées, mais cela ne joue que très peu : moins de 1% de gain !
On peut considérer qu'il n'y a plus guère de possibilités d'améliorer le temps de traitement d'un modèle : tout ce qui pouvait être optimisé l'a été. Ce qu'il reste, ce sont les temps de mise à jour de la base Firebird (l'ordre initial DELETE et les ordres INSERT) qui représentent environ 36% du temps global, les temps de traitement Windev pour "calculer" tous les champs qui ne sont pas issus simplement de la source (20% environ), le reste représentant les temps intrinsèques de traitement Windev, notamment pour tout ce qui touche aux manipulations de chaine de caractère, aux encodage UTF8...
| AMELIORATIONS NOVEMBRE 2013 | Correction N° 32 du 04/11/13 |
Différentes améliorations ont été apportées à cette application. Elles sont décrites au chapitre 6 de la documentation de LDETLFB, qui a fait l'objet d'une révision 2 à cette occasion, datée de novrembre 2013.
| CONNEXION DE TYPE LISTE MAL ENREGISTREES | Correction N° 33 du 03/10/14 |
La correction N° 32 a introduit les connexions de type Liste, permettant de traiter simultanément plusieurs dossiers comptables pour un même modèle au sein d'un scénario. Ces connexions sont enregistrées avec un mot-clé particulier ListeCompta=OUI au sein du fichier Connexion.cnx.
Or, lors de l'enregistrement d'une connexion, il était prévu que ce mot-clé soit inscrit automatiquement en fonction du répertoire (ou de la base de données en HFCS) choisi pour la connexion : si on pouvait accéder dans ce répertoire (ou dans la base de données en HFCS) au fichier CPTSOC, on considérait qu'on était sur une connexion de type Liste.
Il y avait toutefois une erreur lors de l'accès à ce fichier CPTSOC qui faisait que ce mot-clé n'était jamais inscrit. La seule solution consistait à aller l'ajouter manuellement dans le fichier Connexion.cnx.
Désormais, l'enregistrement de ce mot-clé est effectivement automatique en fonction du répertoire ou de la base de données choisi dans la définition de la connexion source.
| DEFINITION DES CONNEXIONS SOURCE - ERREUR SUR UNE CONNEXION AS400 | Correction N° 34 du 29/10/14 |
Suite à la correction 33, quand on définissait une connexion source de type DB2 AS/400, il y avait une erreur au moment de la validation de la connexion. Celle-ci était toutefois correctement enregistrée.
| AMELIORATION SELECTION EXERCICES AVEC CONNEXION DE TYPE LISTE COMPTA | Correction N° 35 du 30/10/14 |
La correction N° 32 avait apporté un certain nombre d'améliorations, dont une possibilité de répéter facilement l'exécution d'un modèle au sein d'un scénario sur tout un ensemble de dossiers comptables.
Une amélioration a été apportée sur les règles de sélection des dossiers comptables à traiter, pour ce qui est de la partie "exercice" (dossiers d'archives.
Rappelons que la sélection se définit sous la forme d'une succession de règles d'inclusion ou d'exclusion, chaque règle portant sur un code société, un intervalle de codes sociétés, ou toutes les sociétés. De plus, dans chacune de ces règles sociétés, on peut ajouter un qualifiant "Exercice", qui fait suite au code société, séparé de celui-ci par ":".
Exemple de règles :
LDD;LDM;LDH : on traite les 3 sociétés LDD, LDM et LDH, exercice courant uniquement
X:LDZ;LDA-LDZ;LD0-LD9 : on traite toutes les sociétés dont le code commence par LD, sauf LDZ, exercice courant uniquement
LDD:*ALL on traite tous les exercices de la société LDD
LD0-LDZ:2012 on traite l'exercice 2012 uniquement de toutes les sociétés dont le code commence par LD
On a désormais 4 possibilités pour l'exercice :
- si l'exercice n'est pas précisé dans la règle, seul l'exercice courant sera pris
- si l'exercice est précisé dans la règle, seul l'exercice indiqué sera pris
- si l'exercice *ALL est indiqué dans la règle, tous les exercices sont pris, y compris l'exercice courant
- NOUVEAU : si l'exercice *ALL>XXXX est précisé dans la règle, l'exercice courant est pris,
ainsi que tous les exercices dont le code (l'année d'archive) est supérieur ou égal au code XXXX indiqué dans la règle
Exemple de règle :
X:LDZ;*ALL:*ALL>2012 : on traite toutes les sociétés sauf la société LDZ, et pour ces sociétés, on traite l'année courante et tous les dossiers d'archives 2012 et postérieurs.
Cette dernière possibilité permet de ne pas surcharger l'entrepôt de données avec des données trop anciennes, notamment quand le nombre de dossiers d'archive "en ligne" est conséquent. Autant il peut s'avérer pratique de conserver 10 ans en ligne, pour pouvoir faire des recherches dans des dossiers "anciens", autant le transfert de tous ces dossiers dans l'entrepôt est préjudiciable, tant en terme de volume de données dans l'entrepôt (qui induit des performances moindres quand on interroge ensuite l'entrepôt) qu'en terme de temps de mise à jour quotidienne de l'entrepôt.
Il est donc préférable de limiter le transfert dans l'entrepôt aux dossiers d'archives relativement récents (entre 3 et 5 ans devraient suffire la plupart du temps).