Les données VisualFoxPro (DBF) dans Windev

WINDEV et les données VFP

Introduction.
Pour les développeurs WINDEV devant utiliser les tables au format Visual FOX PRO, il existe plusieurs solutions .

L’accès natif aux fichiers xBase.
D’après la documentation (page 336 pour WINDEV 17), l’accès natif XBASE permet d’attaquer les tables FOX. Le détail concernant les possibilités de tables VFP et CDX est indiqué au paragraphe 1.2.4 page 337. Il est indiqué que les index CDX sont supportés, ce qui est vrai, mais par contre, il n’est pas indiqué que ceci fonctionne avec le pilote OLEDB. Un petit peu plus de clarté aurait été parfait…

La condition d’accès avec l’accès natif est de ne pas utiliser les index (de toute manière, les index CDX ne sont pas supportés).

Pour les requêtes, en utilisant ce type d’accès, j’ai systématiquement un plantage.

En utilisant la liaison de données avec les champs, tout fonctionne. Les temps d’accès sont relativement acceptables pour des tailles moyennes.

Les index n’étant pas supportés, je n’ai pas testé les fonctions du type HLIT.

Ma conclusion : l’impossibilité d’utiliser des index et des requêtes fait qu’il vaut mieux passer son chemin avec ce type d’accès, même pour consulter les données.

L’accès OLEDB en utilisant les MDAC et le pilote VFP OLEDB.
Cet accès nécessite l’installation du MDAC de MICROSOFT (proposé automatiquement par WINDEV), qui est un des nombreux avatars de l’accès universel aux données de MICROSOFT. En principe, la couche MDAC est installée sur les PC sous XP, VISTA et SEVEN. Attention, dans certains cas, l’installation pose quelques problèmes selon MICROSOFT : dans le cas où l’on veut installer une version plus récente que celle par défaut.

Il faut aussi que le pilote OLEDB de VFP soit installé. Il suffit d’aller à l’adresse suivante :
<http://www.microsoft.com/download/en/details.aspx?id=14839>

Le principal avantage est de pouvoir travailler avec l’IntelliSense et de ne pas avoir à chercher le nom des champs.

Son utilisation est intéressante car elle permet d’utiliser soit des tables indépendantes, soit des conteneurs bases de données.

Pour changer le répertoire des données, la fonction WINDEV HCHANGEREP fonctionne parfaitement, ce qui est plutôt une bonne nouvelle.

Au niveau des index et en mode d’accès classique avec les fonctions du type HLITRECHERCHE, cela fonctionne, à la condition de trouver une valeur. Sinon, c’est une erreur fatale qui est générée. La solution que j’ai trouvée est de faire un traitement d’exception locale, et là pas de problème.
Il est toutefois conseillé de ne travailler que sur les index de type texte, la programmation étant beaucoup plus simple. Pour les index de type numérique ou composé, il faut privilégier les requêtes.

Les requêtes fonctionnent très bien, à la condition de ne pas charger trop de données à la fois, les limitations du pilote OLEDB étant les mêmes que pour tous les pilotes OLEDB du marché.

Pour un accès direct de la table sans passer par une requête, cela fonctionne très bien. J’ai effectué des tests sur une table client de 50 MO comportant 25 000 lignes, et les temps de réponse sont supportables, même en réseau.

Pour des tables de taille beaucoup plus importante, il vaut mieux passer son chemin, un simple comptage du nombre de lignes avec la fonction HNBENR tourne vite au cauchemar, aussi bien en local que sur un réseau.

Ma conclusion : ici encore, il vaut mieux utiliser cette possibilité comme une solution de dépannage, quitte à migrer définitivement les données au format HYPERFILESQ.

L’accès en programmant avec les fonctions WINDEV.
Ceci peut se faire en décrivant la structure des tables en utilisant les fonctions dédiées.
Ceci fonctionne parfaitement bien, à part l’ouverture des index avec la fonction HDBDecritIndex(), qui renvoie systématiquement un message d’erreur.

Voici un exemple de code :
HDBDécritFichier( "CLIENTS" , "CL" , "G:\Win-Moenner\data_quimper\REFCLI01.DBF" )
HDBDécritRubrique("NOM,C,30")
HDBDécritRubrique("PRENOM,C,30")
bVal = HDBOuvre( "CLIENTS" , "CL" , "G:\Win-Moenner\data_quimper\REFCLI01.DBF" )
HLitPremier( "CL" )
TANTQUE PAS HEnDehors("CL")
WL.Trace( i + "----------------->" + NumériqueVersChaîne(i) + CL.NOM
HLitSuivant("CL" )
FIN

Les temps d’accès sont très corrects, mais il y a un problème avec les champs logiques, qui sont reconnus de manière aléatoire (par ailleurs signalé dans la documentation).

J’ai fait un essai de lecture pour un client avec une table de 4 500 00 enregistrements et d’une taille de près de 2 GO, et les temps d’accès sont très corrects.
J’ai réussi sans problème à écrire dans la table VFP en utilisant la fonction HMODIFIE.

Ma conclusion : cette possibilité est à utiliser dans le cas d’une mise à jour d’une table VFP à partir d’une table WINDEV. Les performances sont correctes, mais le problème lié aux champs de type logique pose pas mal de difficultsé. De même, les index n’étant pas supportés, la simple sélection de lignes devient vite problématique.

L’accès avec un composant COM.
Il s’agit d’une autre piste, complexe à mettre en œuvre, mais qui donne de très bons résultats.
VFP permet de créer des composants COM, en créant une DLL OLE à partir d’une classe.
Dans WINDEV, il est possible d’appeler un composant COM, un exemple pilotant les applications MICROSOFT OFFICE montre comment faire.
La difficulté de développer un composant (sous VFP) COM étant de composer avec l’UAC de WINDOWS, ce qui nécessite de développer en mode déconnecté de tout réseau pour des raisons de sécurité.
D’autre part, l’installation d’un composant COM n’est pas une partie de plaisir, mais par contre est possible sous SEVEN 64.

Dans tous les cas, on bénéficie de la puissance du moteur VFP, mais par contre la liaison de données devient impossible dans WINDEV.

L’autre problème important est l’avenir de cette technologie.

Ma conclusion : cette possibilité est a utiliser dans des cas très particuliesr, sur des liaisons de tables complexe par exemple.

Conclusions.
Pour intégrer des tables VFP dans une application WINDEV, la seule solution vraiment pratique est d’utiliser OLEDB. Parc contre, les tables ne doivent pas être trop volumineuses. Par exemple, si un fichier client est parfaitement exploitable, une table contenant de nombreuses factures et lignes de factures ne peut poser que des problèmes.
Tant qu’il s’agit de petites tables, tout est facile, pour les autres, il est temps de migrer…

Marc MIRVILLE, modifié le 12/12/2011.