DESCRIPTIF DES CORRECTIONS
Entrepôt de données Version 1.00 - Corrections 1 à 23

ORTHOGRAPHE : SCENARII DEVIENT SCENARIOSCorrection 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 JOURCorrection 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 DIVERSESCorrection 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 PERFORMANCESCorrection 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 TEXTCorrection 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 TEXTCorrection 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 DONNEESCorrection 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 CHAMPSCorrection 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 TRAITEMENTCorrection 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'ANNULATIONCorrection 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'EXECUTIONCorrection 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.