DBToFile2 : Une amélioration de DBToFile1
La version 2 permet de gérer plus simplement plusieurs types d'archivage, sans avoir à dupliquer dans DBToFile.mdb les informations sur les tables à archiver.
Exemple d'utilisation : VBBrainBox :
http://patrice.dargenton.free.fr/ia/vbbrainbox/index.html
Téléchargement
http://patrice.dargenton.free.fr/dbtofile/DBToFile2Inst.zip (4 Mo, dernière m.à.j.: le 22/09/2007, version 2.0.0.16 du 16/09/2007)
Versions
Version 2.0.0.16 du
16/09/2007
- Traitement pour ignorer les chaînes contenant un seul " en lecture, car lorsque l'on applique la fonction Trim le guillemet disparaît et on peut obtenir l'erreur "Chaîne vide interdite", si le champ est ainsi contraint dans la base de données (on pourrait aussi l'éviter lors de l'écriture, mais du moment que c'est traité en lecture, cela suffit).
Version 2.0.0.15 du
17/06/2007
- Traitement des sauts de ligne particuliers dans les champs mémo (ils provoquent un saut de ligne pour la fonction VB6 Line Input) : correction en vbCrLf des vbCr (chr$(13)) non suivis de vbLf (chr$(10)), ils sont probablement dus à un copier/coller de texte avec des conventions différentes pour les sauts de lignes ; correction aussi en vbCrLf des vbNullChar (chr$(0)), ils sont probablement dus à un plantage Access réparé lors d'un compactage.
Version 2.0.0.12, 13
et 14 du 30/10/2005
- La gestion des sauts de ligne a parfois des ratés en VB6 (fonctions Line Input et InStr), du coup il n'est plus possible de conserver des sauts de lignes vides dans le contenu d'un champ texte ou mémo, on est maintenant obligé de compter les seules lignes non vides dans ces champs, et elles seront perdues lors d'un transfert via un fichier d'archive. La perte n'est pas très grave, mais depuis 1999, le principe de DBToFile est basé sur la conservation parfaite du contenu des champs textes et binaires, ce n'est plus possible pour les sauts de lignes vides en VB6, mais une version DotNet2 rétablira j'espère ce principe, et le code source sera publié cette fois (par contre je ne peux pas dire quand cela se fera, car je n'ai pas suffisamment de temps de libre pour le moment).
Version 2.0.0.11 du 31/05/2005
- Les valeurs booléennes
fausses ne sont plus ignorées au moment de produire le fichier d'archive, car
sinon on ne peut pas mettre ces booléens à faux lors d'un rechargement
Version 2.0.0.10 du 26/03/2005
- Champ unique introuvable :
une description précise de l'erreur est maintenant affichée
- Si l'extension du nom du
fichier d'archive n'a que 2 caractères, le nom du fichier .bak est maintenant
correct
- Gestion de l'annulation
améliorée lors de la lecture d'une archive : maintenant bLoadArchivFile
renvoie bien Faux dans ce cas
- Correction de l'erreur
3052 avec MaxLocksPerFile lors de la lecture d'une
archive volumineuse :
http://support.microsoft.com/kb/198633/en-us
Solution
trouvée : augmenter le nombre max. de verrous autorisés, soit 500000 (puisque
l'on n'est pas concerné par la limite sous Novel à
9500 et que ce changement est temporaire, il est lié seulement à l'instance
courante de DBEngine)
Version 2.0.0.9 du 12/02/2005
- Gestion des index sur les
champs date
Version 2.0.0.8 du 08/11/2003
- Gestion de la confirmation
lors de la création du rapport
Version 2.0.0.7 du 17/06/2003 et 21/06/2003
- Ajout de la propriété bCancel pour demander une annulation lorsqu'il n'y a pas
d'interface : 21/06/2003
- Gestion de la confirmation
aussi pour création d'une base vide (suppression de tous les enregistrements) :
17/06/2003
Version 2.0.0.6 du 14/06/2003 et 16/06/2003
- Ajout de la propriété bNoConfirm pour activer le mode automatique : 16/06/2003
- Ajout de la propriété strProgress pour voir l'avancement sans l'interface, en
utilisant CreateObject("DBToFile.UserControl1") : 14/06/2003
Version 2.0.0.5 du 17/03/2003
- Si une table sélectionnée
dans les SQL est incorrecte, un message est affiché
Version 2.0.0.4 du 01/02/2003
- Bug doublons corrigé lors
de la détection d'un nouvel enregistrement
Version 2.0.0.3
- Null
interdit précisé dans le rapport
Version 2.0.0.1 du 17/08/2001