4.1HFSQL Client/Serveur : installation & administration
L'essentiel en 30 secondes
- En CLIENT/SERVEUR, un serveur centralise les données : les applications lui envoient des requêtes, il les traite et ne renvoie que les résultats — trafic réseau effondré, performance et robustesse en multi-utilisateurs, sécurité et accès distants.
- Bonne nouvelle pour la migration : l'ANALYSE ne change pas et le code WLangage reste très largement identique (les fonctions H marchent dans les deux modes) ; l'essentiel du travail porte sur l'installation, la migration des données et la connexion.
- Deux notions clés : les TRANSACTIONS (tout ou rien) et le BLOCAGE (accès concurrents) ; ⚠️ un serveur de données exige une vraie administration : supervision, mises à jour et surtout sauvegardes automatisées ET TESTÉES.
Mini-cas filé — Yacine passe son négoce en HFSQL Client/Serveur
Yacine, développeur WinDev dans une PME de négoce de matériel électrique à Oran, a bâti une application de gestion (clients, produits, commandes, factures, stocks). Elle tourne en HFSQL Classic : les fichiers de données sont posés sur un partage réseau et chaque poste les lit directement. À six utilisateurs (commerciaux, magasinier, comptable) travaillant en même temps, les lenteurs s'aggravent aux heures de pointe, et une coupure réseau pendant une saisie de commande a laissé un stock débité sans commande correspondante — une incohérence silencieuse. Yacine décide de basculer en HFSQL Client/Serveur : il installe le serveur HFSQL sur une machine dédiée, migre les données depuis le Classic, crée les utilisateurs et leurs droits côté serveur, puis paramètre la connexion dans l'application. Il retient deux réflexes : envelopper l'opération « commande + lignes + stock » dans une transaction courte (tout ou rien) et gérer les blocages entre utilisateurs. Enfin il met en place des sauvegardes automatisées, stockées ailleurs, et en teste une restauration réelle. Il note le principe : l'analyse ne change pas, le code H reste le même ; le travail est dans l'installation, la migration et la connexion.
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 4.1.
1. Un serveur qui centralise
Passer en HFSQL Client/Serveur change l'architecture. En Classic, chaque poste lit directement les fichiers de données sur le disque local ou un partage réseau ; en Client/Serveur, un serveur centralise tout : les applications lui envoient des requêtes, il les traite et ne renvoie que les résultats. Les bénéfices sont majeurs : le trafic réseau s'effondre (seules les données utiles circulent), les accès concurrents sont gérés par le moteur, le risque de corruption diminue fortement, la sécurité (authentification, droits, chiffrement) devient possible, et les accès distants (télétravail, agences) sont enfin sains. Côté administration : supervision, sauvegardes y compris à chaud, maintenance centralisée.
2. Installer, migrer, connecter
Concrètement, il faut installer et administrer le serveur. (1) Installation du serveur HFSQL sur une machine correctement dimensionnée (processeur, mémoire, disque). (2) Création des bases et migration des données depuis le Classic. (3) Gestion des utilisateurs et des droits côté serveur (qui peut lire, écrire, administrer). (4) Paramétrage de la connexion dans l'application (serveur, port, identifiants). Bonne nouvelle pour la migration : comme l'analyse ne change pas et que le code WLangage reste identique, l'essentiel du travail se concentre sur ces étapes-là.
3. Transactions & blocage
Deux notions à maîtriser. Les transactions garantissent qu'un ensemble d'écritures est fait entièrement ou pas du tout : enregistrer une commande, c'est créer l'en-tête, les lignes, décrémenter le stock et mettre à jour le total du client — si une interruption survient au milieu, on obtient une commande sans lignes ou un stock débité sans commande. La transaction évite cet état incohérent silencieux, et gère l'isolation entre utilisateurs. Le blocage gère le cas où deux utilisateurs modifient le même enregistrement : empêcher la modification concurrente (pessimiste) ou détecter le conflit à l'enregistrement (optimiste) — l'essentiel étant qu'aucune modification ne soit écrasée silencieusement (la « mise à jour perdue »). Gardez les transactions courtes : jamais de transaction ouverte en attendant une saisie.
🔎 Exemple concret — 🔎 Exemple concret — Connexion & transaction
Le squelette d'une application passée en Client/Serveur, comme celle de Yacine :
// 1) Connexion au serveur HFSQL de la PME (Oran)
SI HOpenConnection("CnxNegoce", "srv-oran", "yacine", sMdp, hOuvre) = VRAI ALORS
HChangeConnection("*", "CnxNegoce")
SINON
Erreur("Serveur HFSQL injoignable : " + HErreurInfo())
FIN
// 2) Enregistrer une commande : TOUT OU RIEN
HTransaction("CnxNegoce")
SI HAjoute(Commande) ET HAjoute(LigneCommande) ALORS
HTransactionFin("CnxNegoce") // validé : tout est définitif
SINON
HTransactionAnnule("CnxNegoce") // annulé : rien n'est écrit
FINLecture : le serveur est désigné par son nom et la connexion devient la référence pour toutes les fonctions H de l'application.
Leçon : la transaction enveloppe l'opération métier « commande + lignes + stock » : soit tout est écrit, soit rien — jamais d'incohérence silencieuse.
Vocabulaire de la section
- Architecture Client/Serveur
- Un serveur centralise les données : les applications lui envoient des requêtes, il traite et ne renvoie que les résultats.
Exemple simple : Yacine installe un serveur HFSQL pour son négoce à six postes.
Ce que ce n'est pas : le mode Classic, où chaque poste lit directement les fichiers.
Réflexe : centraliser et fiabiliser → le Client/Serveur.
- Migration depuis Classic
- Passage au Client/Serveur : l'analyse ne change pas et le code WLangage reste très largement identique — le travail porte sur l'installation, la migration des données et la connexion.
Exemple simple : Yacine migre ses données Classic vers le serveur sans retoucher son analyse.
Ce que ce n'est pas : une réécriture complète de l'application.
Réflexe : changer d'architecture sans tout réécrire → la migration.
- Transaction
- Garantir qu'un ensemble d'écritures est effectué entièrement ou pas du tout (commande + lignes + stock, jamais l'un sans l'autre).
Exemple simple : Yacine enveloppe la saisie de commande dans une transaction courte.
Ce que ce n'est pas : quatre écritures indépendantes, chacune validée séparément.
Réflexe : opération composée → une transaction.
- Blocage (accès concurrents)
- Mécanisme gérant le cas où deux utilisateurs modifient le même enregistrement, pour éviter qu'une modification en écrase silencieusement une autre.
Exemple simple : Yacine gère le blocage entre deux commerciaux sur la même fiche client.
Ce que ce n'est pas : laisser deux postes écrire sans contrôle (mise à jour perdue).
Réflexe : éviter la mise à jour perdue → le blocage.
- Administration (⚠️)
- Un serveur de données exige une vraie administration : supervision, utilisateurs et droits, mises à jour, et sauvegardes automatisées ET TESTÉES.
Exemple simple : Yacine automatise ses sauvegardes et en restaure une pour vérifier.
Ce que ce n'est pas : « installer et oublier », sans supervision ni sauvegarde.
Réflexe : un serveur se gère → l'administration.
En pratique — En pratique — Mettre en place HFSQL Client/Serveur
- Installez le serveur HFSQL sur une machine correctement dimensionnée, puis créez la base et migrez les données depuis le mode Classic, comme Yacine.
- Configurez les utilisateurs et leurs droits côté serveur (lecture, écriture, administration), puis paramétrez la connexion dans l'application.
- Utilisez les transactions pour les opérations composées de plusieurs écritures liées (tout ou rien) et gérez proprement les blocages entre utilisateurs.
- Mettez en place des sauvegardes automatisées, stockées ailleurs, et testez une restauration — une sauvegarde jamais testée ne vaut rien.
Script pas-à-pas — passer en Client/Serveur comme Yacine (5 min)
1) Installez et dimensionnez le serveur HFSQL sur une machine dédiée. 2) Créez la base et migrez les données depuis le Classic. 3) Définissez les utilisateurs et leurs droits côté serveur (lecture, écriture, administration). 4) Paramétrez la connexion dans l'application (serveur, port, identifiants). 5) Enveloppez la saisie de commande dans une transaction courte et vérifiez qu'une erreur annule bien toutes les écritures. 6) Automatisez les sauvegardes, stockez-les ailleurs et testez une restauration réelle.
L'analyse et le code H ne changent pas : concentrez-vous sur l'installation, la migration, la connexion et l'administration (sauvegardes testées).
Modèle copier-coller — ma fiche Client/Serveur
Classic : fichiers sur partage reseau, acces direct
Client/Serveur : serveur central, requetes -> resultats
Migration : analyse inchangee, code H identique
Connexion : serveur + port + identifiants (HOpenConnection)
Transactions : commande + lignes + stock = TOUT OU RIEN
Acces concurrents : gerer le BLOCAGE (eviter la MAJ perdue)
Administration : sauvegardes automatisees, stockees ailleurs ET TESTEESBascule Classic → C/S
Yacine migre les données de son partage réseau vers un serveur HFSQL central.
Transaction courte
Yacine enveloppe « commande + lignes + stock » dans une transaction tout ou rien.
Blocage géré
Yacine empêche deux commerciaux d'écraser mutuellement la même fiche client.
Sauvegarde testée
Yacine restaure une sauvegarde sur une machine de test pour vérifier qu'elle est exploitable.
✓ Bonnes pratiques
- Migrer sans réécrire : l'analyse et le code H ne changent pas.
- Garder les transactions courtes et gérer le blocage des accès concurrents.
- Automatiser les sauvegardes et en tester une restauration.
✗ Pièges fréquents
- Croire que le passage en C/S oblige à tout réécrire.
- Laisser le Classic sur partage réseau avec beaucoup d'utilisateurs.
- Sauvegarder sans jamais tester la restauration.
Points clés à retenir
- En Client/Serveur, un serveur centralise les données et ne renvoie que les résultats : performance, robustesse, sécurité et accès distants.
- La migration ne change ni l'analyse ni le code H : le travail porte sur l'installation, les données et la connexion.
- Transactions (tout ou rien) et blocage (accès concurrents) garantissent la cohérence.
- ⚠️ Un serveur exige une vraie administration : supervision, droits, mises à jour et sauvegardes testées.
Défi 48h — appliquez demain
Comme Yacine, dressez le bilan de votre application : combien d'utilisateurs simultanés, quels volumes, quelles lenteurs ? S'il y a un signal de bascule, installez un serveur HFSQL de test, migrez une copie des données et paramétrez la connexion. Enveloppez ensuite une opération composée (commande + lignes + stock) dans une transaction courte et provoquez une erreur pour vérifier qu'aucune écriture partielle ne subsiste. Terminez par une sauvegarde restaurée sur une machine de test.
- Je sais quand passer de HFSQL Classic à Client/Serveur.
- J'installe le serveur, migre les données et configure la connexion.
- J'utilise les transactions et le blocage, avec des sauvegardes testées.
Questions fréquentes
Quand faut-il passer de HFSQL Classic à HFSQL Client/Serveur ?
Passez en Client/Serveur dès que plusieurs utilisateurs travaillent simultanément de façon intensive (le critère n°1), que les volumes grossissent, que vous avez besoin de sécurité fine ou d'accès distants — le Classic reste parfait en monoposte ou pour quelques postes en usage léger. Les signaux : lenteurs croissantes aux heures de pointe, incidents de corruption, besoin de droits par utilisateur ou de chiffrement, télétravail. Bonne nouvelle pour la migration : l'analyse ne change pas et le code WLangage reste très largement identique. On installe le serveur, on migre les données et on met à jour les paramètres de connexion.
Pourquoi les transactions sont-elles indispensables en multi-utilisateurs ?
Parce qu'une opération métier implique souvent plusieurs écritures qui doivent réussir ensemble. Enregistrer une commande, c'est créer l'en-tête, créer les lignes, décrémenter le stock et mettre à jour le total du client : quatre écritures pour une seule opération. Sans transaction, une panne ou une coupure après la deuxième écriture laisse une commande sans lignes ou un stock débité sans commande — une incohérence silencieuse, découverte des semaines plus tard. La transaction garantit le tout ou rien : on l'ouvre, on écrit, puis on valide ou on annule. Elle gère aussi l'isolation entre utilisateurs et s'articule avec les blocages.
Pourquoi les transactions sont-elles indispensables en HFSQL multi-utilisateurs ?