FoxSQL : apprendre SQL à AccountView sans laisser ODBC prendre le contrôle

L'idée a commencé par une question simple mais dangereuse: pouvons-nous faire en sorte que les données AccountView ressemblent à une connexion de base de données normale à partir de C#? Pas "exporter un CSV et prier. " Pas " installer un autre fournisseur générique et prétendre 1998 est bien. " Une véritable API client: ouvrir une connexion, envoyer SQL, lier des paramètres, recevoir des lignes, page à travers de grands ensembles de résultats, et inspecter les diagnostics lorsque la machine commence à transpirer.

Cette question est importante parce que de nombreux systèmes commerciaux sont pleins de précieuses données FoxPro qui fonctionnent toujours bien dans l'entreprise, tandis que le logiciel qui l'entoure est passé à des tableaux de bord Web, des écrans mobiles, des API, des services, des files d'attente et des développeurs qui deviennent nerveux quand une intégration de production dépend d'un lecteur cartographié et de bonnes vibrations.

La première décision était la plus importante: FoxSQL n'essaie pas de devenir un nouveau FoxPro. Il ne réimplemente pas DBF, CDX, FPT, verrouillage, tamponage ou les nombreuses petites règles qui vivent à l'intérieur AccountView. Au lieu de cela, le service garde Visual FoxPro dans le chemin d'exécution. FoxSQL fournit le pont moderne; Fox conserve la propriété du comportement des données. C'est moins glamour que d'inventer un moteur de base de données, mais beaucoup moins susceptible de ruiner la journée comptable de quelqu'un.

Ce que FoxSQL peut faire aujourd'hui

La forme du pont

L'architecture de travail est délibérément pragmatique: une application C# parle à FoxSQL.Client; le client ouvre une connexion TCP regroupée à FoxSQL.Service; le service sérialise l'accès au temps d'exécution Fox et exécute la route SQL approuvée. Visual FoxPro reste le moteur des requêtes complexes et de la mutation des données. C++ gère le bas niveau Windows et la réalité face à Fox, parce que le COM à 32 bits ne devient pas élégant juste parce que nous demandons gentiment.

Cette séparation est importante. C# ne modifie jamais directement les fichiers DBF/CDX/FPT. Le pont évite un appel COM par rangée. Le travail Fox coûteux est mesuré. Les écrits sont derrière les portes de configuration. Et quand un écran a besoin de la page 17 d'un grand résultat trié, FoxSQL peut obtenir une fenêtre de rangées au lieu de reconstruire l'univers pour la dix-septième fois.

Comment la construction a-t-elle vraiment eu lieu ?

Le processus n'était pas une ligne droite, ce qui est généralement la façon dont vous savez qu'il a touché un logiciel réel. La première phase était un pic de faisabilité: prouver que FoxPro et AccountView pouvaient être atteints, prouver que les données pouvaient se déplacer sans OLE DB ou ODBC, et prouver que le service pouvait maintenir un temps d'exécution en vie au lieu de faire un travail de démarrage coûteux par déclaration.

À partir de là, le projet s'est développé en couches: d'abord le protocole et C# contrat client, puis la sérialisation des résultats, puis la classification SQL et la liaison des paramètres, puis la pagination, les règles de mutation, les itinéraires chauds de mise à jour / suppression spécifiques à RECNO, l'invalidation du cache de résultats, le pooling de connexions, le scrubbing d'état Fox partagé, la réutilisation de tampons, la lecture en vrac des résultats DBF, et enfin les curseurs explicites du côté du serveur. En d'autres termes: le type amusant de plomberie, où chaque milliseconde a une étiquette de nom.

Les paramètres de référence ont façonné la conception. Une mise à jour naïve WHERE RECNO() = ... peut se transformer en une promenade de table accidentelle si elle prend la mauvaise route. FoxSQL a ajouté des chemins de numérotation de disques dédiés qui utilisent le positionnement de disques natifs pour les cas où l'application connaît déjà le disque. Ce n'est pas une optimisation prématurée; c'est voir le trou, l'étiquetage et mettre un petit pont dessus.

Qu'est-ce qui vient ensuite ?

La prochaine étape consiste à rendre FoxSQL utile au-delà des applications .NET. Le client C# est la première interface sérieuse car il nous donne un contrat en forme de base de données approprié: chaînes de connexion, commandes, paramètres, adaptateurs, lecteurs, curseurs et manipulation d'erreurs prévisible. Mais le pont n'est pas destiné à s'arrêter au bureau ou au code service-à-service C#.

Un mode de réponse direct JSON est planifié afin que les appelants puissent demander FoxSQL pour des données et recevoir JSON propre sans tout transformer en un tableau de données. Cela ouvre la porte à des intégrations légères, des panneaux d'administration, des terminaux mobiles et des outils Web où JSON est la forme naturelle de la conversation. Le chemin de file d'attente binaire peut rester rapide pour les clients lourds; JSON peut devenir la porte d'entrée conviviale pour tout le reste.

Cela signifie également que les sites Web PHP peuvent devenir des consommateurs de première classe. Un site PHP devrait être en mesure d'appeler FoxSQL, d'exécuter une requête approuvée, de lier des paramètres et de rendre en direct AccountView des données sur une page sans toucher aux fichiers DBF, d'installer ODBC pilotes ou d'enseigner aux serveurs Web les anciens rituels de bureau. Le site Web demande des données; FoxSQL traite la réalité FoxPro; AccountView reste la source de vérité.

À ce moment-là FoxSQL devient ce que le nom a toujours visé: une véritable couche de serveur SQL au-dessus de FoxPro et AccountView. Pas Microsoft SQL Server, pas un faux costume en forme de base de données, mais un véritable processus de serveur avec un protocole, une authentification, une validation de requête, des politiques d'exécution, des diagnostics, des formats de résultats et plusieurs types de clients. Moins de rituels nocturnes impliquant des chauffeurs installés.

Le coup de poing

FoxSQL est intéressant parce qu'il ne prétend pas que les données héritées deviennent modernes en les enveloppant dans un vocabulaire à la mode. Il respecte l'ancien moteur, contient les pièces dangereuses et offre aux applications modernes une façon disciplinée de: connexions regroupées, commandes paramétrisées, rowsets, diagnostics, pagination, curseurs, pistes d'intégration JSON prêtes, outils d'installation et un service Windows qui peut être validé au lieu de souhaité dans la production.

Le résultat est un pont avec juste assez d'attitude: FoxPro continue de faire FoxPro choses, C# obtient une API en forme de base de données appropriée, PHP obtient un itinéraire propre pour les données commerciales en direct, et ODBC peut enfin cesser d'être blâmé pour chaque requête lente dans le bâtiment.