Actualités
FoxSQL est une passerelle SQL sur TCP/IP pour les données AccountView et Visual FoxPro. Les applications C# utilisent les concepts familiers des bases de données, tandis que le véritable moteur FoxPro continue d’assurer son rôle. Personne n’a à déchiffrer des fichiers DBF à la lueur d’une bougie.
Tout est parti d’une question simple, mais risquée : peut-on accéder aux données AccountView depuis C# comme à une base de données ordinaire ? Sans exporter un CSV en croisant les doigts, ni installer un énième fournisseur générique en prétendant que 1998 n’est pas si loin. Une vraie API cliente : ouvrir une connexion, envoyer du SQL, lier des paramètres, recevoir des lignes, parcourir de grands résultats par pages et consulter les diagnostics lorsque la machine peine.
La question compte, car de nombreux systèmes métier contiennent de précieuses données FoxPro qui font encore très bien fonctionner l’entreprise. Autour d’eux, le logiciel est passé aux tableaux de bord web, écrans mobiles, API, services et files d’attente, avec des développeurs peu rassurés lorsqu’une intégration en production dépend d’un lecteur réseau et d’un optimisme sans faille.
La première décision était la plus importante : FoxSQL ne cherche pas à réinventer FoxPro. Il ne réimplémente ni DBF, CDX, FPT, ni les verrous, la mise en mémoire tampon ou les multiples règles internes d’AccountView. Le service conserve Visual FoxPro dans la chaîne d’exécution. FoxSQL fournit la passerelle moderne ; Fox reste responsable du comportement des données. C’est moins spectaculaire qu’inventer un moteur de base de données, mais bien moins susceptible de gâcher la journée du service comptable.
FoxSqlConnection, FoxSqlCommand, FoxSqlDataAdapter, et FoxSqlCursor. On travaille ainsi avec une base de données, sans avoir besoin d’un permis de fouilles archéologiques.L’architecture est volontairement pragmatique : une application C# appelle FoxSQL.Client, qui ouvre une connexion TCP issue d’un pool vers FoxSQL.Service. Le service sérialise l’accès au moteur Fox et exécute le parcours SQL autorisé. Visual FoxPro reste le moteur des requêtes complexes et des modifications de données. C++ gère les détails bas niveau de Windows et de Fox, car COM 32 bits ne devient pas élégant simplement parce qu’on le lui demande gentiment.
Application C# -> FoxSQL.Client -> connexion TCP issue d’un pool -> FoxSQL.Service -> données Visual FoxPro / AccountView -> trame binaire de lignes renvoyée à C#Cette séparation compte. C# ne modifie jamais directement les fichiers DBF/CDX/FPT. La passerelle évite un appel COM par ligne. Les opérations Fox coûteuses sont mesurées. Les écritures nécessitent une activation dans la configuration. Et lorsqu’un écran demande la page 17 d’un grand résultat trié, FoxSQL peut récupérer une plage de lignes sans reconstruire l’univers pour la dix-septième fois.
Le processus n’a pas été linéaire, comme souvent lorsqu’on travaille sur un vrai logiciel. La première phase était une exploration de faisabilité : vérifier l’accès à FoxPro et AccountView, le transfert de données sans OLE DB ni ODBC et la capacité du service à maintenir un moteur actif, au lieu de payer le coût de son démarrage à chaque instruction.
Le projet s’est ensuite construit par couches : protocole et contrat du client C#, sérialisation des résultats, classification SQL et liaison des paramètres, pagination, règles de modification, chemins optimisés de mise à jour et de suppression par RECNO, invalidation du cache, pool de connexions, nettoyage de l’état Fox partagé, réutilisation des tampons, lecture groupée des résultats DBF et, enfin, curseurs explicites côté serveur. De la plomberie technique comme on l’aime, où chaque milliseconde porte une étiquette.
Les mesures de performance ont orienté la conception. Une mise à jour naïve avec WHERE RECNO() = ... peut parcourir accidentellement toute la table si elle suit le mauvais chemin. FoxSQL a donc ajouté des traitements dédiés par numéro d’enregistrement, avec positionnement natif lorsque l’application connaît déjà la ligne. Ce n’est pas une optimisation prématurée : c’est repérer le nid-de-poule, le signaler et construire un petit pont au-dessus.
La prochaine étape est d’ouvrir FoxSQL au-delà des applications .NET. Le client C# constitue la première interface complète, car il offre un véritable contrat de base de données : chaînes de connexion, commandes, paramètres, adaptateurs, lecteurs, curseurs et gestion prévisible des erreurs. Mais la passerelle n’est pas destinée à rester limitée aux applications de bureau ou aux échanges entre services en C#.
Un mode de réponse JSON direct est prévu : les appelants pourront demander des données et recevoir un JSON clair, sans passer d’abord par un DataTable. Cela permettra des intégrations légères, panneaux d’administration, points d’accès mobiles et outils web pour lesquels JSON est le format naturel. Les résultats binaires pourront rester rapides pour les clients exigeants ; JSON fournira une entrée simple pour les autres.
Les sites PHP pourront ainsi devenir des clients à part entière. Un site doit pouvoir appeler FoxSQL, exécuter une requête autorisée, lier des paramètres et afficher les données AccountView à jour sans toucher aux fichiers DBF, installer de pilotes ODBC ou enseigner au serveur web les rituels d’un ancien logiciel de bureau. Le site demande les données, FoxSQL gère les particularités de FoxPro et AccountView reste la source de référence.
FoxSQL deviendra alors ce que son nom annonce depuis le début : une véritable couche de serveur SQL au-dessus de FoxPro et d’AccountView. Pas Microsoft SQL Server, ni un simple déguisement de base de données, mais un vrai processus serveur avec protocole, authentification, validation des requêtes, règles d’exécution, diagnostics, formats de résultats et plusieurs types de clients. Des données anciennes, un accès moderne, des frontières claires et moins de rituels nocturnes autour des installateurs de pilotes.
L’intérêt de FoxSQL est de ne pas prétendre moderniser les données anciennes en les habillant d’un vocabulaire à la mode. Il respecte le moteur existant, encadre les opérations risquées et offre un accès rigoureux aux applications modernes : connexions mutualisées, commandes paramétrées, ensembles de lignes, diagnostics, pagination, curseurs, parcours d’intégration préparés pour JSON, outils d’installation et service Windows vérifiable avant sa mise en production.
Le résultat est une passerelle avec juste ce qu’il faut de caractère : FoxPro continue de faire son travail, C# dispose d’une véritable API de base de données, PHP bénéficie d’un accès clair aux données métier à jour et ODBC peut enfin cesser d’être accusé de toutes les requêtes lentes du bâtiment.
À découvrir
Comment un scanner de tickets est devenu, à partir d’un paquet Swift testable, une plateforme iPhone, iPad et macOS respectueuse de la vie privée : OCR, Core ML, synchronisation CloudKit, exports, outils d’entraînement, audits de production et une compréhension durement acquise des difficultés que les tickets posent au logiciel.
Hamlet est l’un des développements majeurs de notre feuille de route : un éditeur natif de texte enrichi, de mise en page et de publication depuis les données, conçu pour 4D. L’objectif : offrir un éditeur complet intégrable dans un formulaire 4D, utilisant les données réelles de la base pour produire des factures, rapports, lettres, modèles et publications professionnels.
Nous avons achevé une modernisation majeure de 4D Agenda : ce plug-in classique du début des années 2000 dispose désormais d’un code macOS propre, stable et moderne. Le code d’origine, datant d’environ 2003, avait longtemps bien servi, mais accumulait les anciens rendus, branches de plateformes, hypothèses du Mac classique et couches de compatibilité dignes d’un musée.
