4.1HFSQL Client/Serveur: installation & administration
The essentials in 30 seconds
- In CLIENT/SERVEUR mode, a server centralizes the data: applications send it queries, it processes them and returns only the results — network traffic collapses, performance and robustness in multi-user mode, security and remote access.
- Good news for migration: the ANALYSIS does not change and the WLangage code remains very largely identical (H functions work in both modes); most of the work concerns installation, data migration and the connection.
- Two key notions: TRANSACTIONS (all or nothing) and LOCKING (concurrent access); ⚠️ a data server requires real administration: monitoring, updates and above all automated AND TESTED backups.
Mini-case thread — Yacine moves his trading business to HFSQL Client/Serveur
Yacine, a WinDev developer at an electrical equipment trading SME in Oran, has built a management application (customers, products, orders, invoices, stock). It runs on HFSQL Classic: the data files sit on a network share and each workstation reads them directly. With six users (salespeople, storekeeper, accountant) working at the same time, slowdowns get worse at peak hours, and a network outage during order entry left stock decremented without a matching order — a silent inconsistency. Yacine decides to switch to HFSQL Client/Serveur: he installs the HFSQL server on a dedicated machine, migrates the data from Classic, creates the users and their rights on the server side, then configures the connection in the application. He keeps two reflexes: wrap the 'order + lines + stock' operation in a short transaction (all or nothing) and handle locks between users. Finally he sets up automated backups stored elsewhere, and tests a real restore. He notes the principle: the analysis does not change, the H code stays the same; the work is in installation, migration and connection.
Standalone case for this section: it returns in the course, the diagram, the script and the 48h challenge of section 4.1.
1. A server that centralizes
Switching to HFSQL Client/Serveur changes the architecture. In Classic mode, each workstation reads the data files directly on the local disk or a network share; in Client/Serveur mode, a server centralizes everything: applications send it queries, it processes them and returns only the results. The benefits are major: network traffic collapses (only useful data travels), concurrent access is handled by the engine, the risk of corruption drops sharply, security (authentication, rights, encryption) becomes possible, and remote access (teleworking, branches) finally becomes sound. On the administration side: monitoring, backups including hot backups, centralized maintenance.
2. Install, migrate, connect
Concretely, you must install and administer the server. (1) Install the HFSQL server on a properly sized machine (processor, memory, disk). (2) Create the databases and migrate the data from Classic. (3) Manage users and rights on the server side (who can read, write, administer). (4) Configure the connection in the application (server, port, credentials). Good news for migration: since the analysis does not change and the WLangage code remains identical, most of the work focuses on these steps.
3. Transactions & locking
Two notions to master. Transactions guarantee that a set of writes is done entirely or not at all: saving an order means creating the header, the lines, decrementing stock and updating the customer total — if an interruption occurs midway, you get an order without lines or stock decremented without an order. The transaction avoids this silent inconsistent state, and manages isolation between users. Locking handles the case where two users modify the same record: prevent concurrent modification (pessimistic) or detect the conflict on save (optimistic) — the essential thing being that no modification is silently overwritten (the 'lost update'). Keep transactions short: never leave a transaction open while waiting for input.
🔎 Concrete example — 🔎 Concrete example — Connection & transaction
The skeleton of an application switched to Client/Serveur, like Yacine's:
// 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
FINReading: the server is designated by its name and the connection becomes the reference for all H functions in the application.
Lesson: the transaction wraps the business operation 'order + lines + stock': either everything is written or nothing is — never a silent inconsistency.
Section vocabulary
- Client/Serveur architecture
- A server centralizes the data: applications send it queries, it processes them and returns only the results.
Simple example: Yacine installs an HFSQL server for his six-workstation trading business.
What it is not: Classic mode, where each workstation reads the files directly.
Reflex: centralize and make reliable → Client/Serveur.
- Migration from Classic
- Switching to Client/Serveur: the analysis does not change and the WLangage code remains very largely identical — the work concerns installation, data migration and the connection.
Simple example: Yacine migrates his Classic data to the server without touching his analysis.
What it is not: a complete rewrite of the application.
Reflex: change architecture without rewriting everything → migration.
- Transaction
- Guarantee that a set of writes is performed entirely or not at all (order + lines + stock, never one without the other).
Simple example: Yacine wraps order entry in a short transaction.
What it is not: four independent writes, each validated separately.
Reflex: composite operation → a transaction.
- Locking (concurrent access)
- Mechanism handling the case where two users modify the same record, to prevent one modification from silently overwriting another.
Simple example: Yacine handles locking between two salespeople on the same customer record.
What it is not: letting two workstations write without control (lost update).
Reflex: avoid the lost update → locking.
- Administration (⚠️)
- A data server requires real administration: monitoring, users and rights, updates, and automated AND TESTED backups.
Simple example: Yacine automates his backups and restores one to verify it.
What it is not: 'install and forget', with no monitoring or backup.
Reflex: a server must be managed → administration.
In practice — In practice — Set up HFSQL Client/Serveur
- Install the HFSQL server on a properly sized machine, then create the database and migrate the data from Classic mode, like Yacine.
- Configure the users and their rights on the server side (read, write, administration), then configure the connection in the application.
- Use transactions for composite operations involving several linked writes (all or nothing) and handle locks between users properly.
- Set up automated backups stored elsewhere, and test a restore — an untested backup is worth nothing.
Step-by-step script — switch to Client/Serveur like Yacine (5 min)
1) Install and size the HFSQL server on a dedicated machine. 2) Create the database and migrate the data from Classic. 3) Define the users and their rights on the server side (read, write, administration). 4) Configure the connection in the application (server, port, credentials). 5) Wrap order entry in a short transaction and check that an error really cancels all writes. 6) Automate backups, store them elsewhere and test a real restore.
The analysis and H code do not change: focus on installation, migration, connection and administration (tested backups).
Copy-paste template — my Client/Serveur sheet
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 TESTEESClassic → C/S switch
Yacine migrates the data from his network share to a central HFSQL server.
Short transaction
Yacine wraps 'order + lines + stock' in an all-or-nothing transaction.
Managed locking
Yacine prevents two salespeople from overwriting the same customer record.
Tested backup
Yacine restores a backup on a test machine to verify that it is usable.
✓ Best practices
- Migrate without rewriting: the analysis and H code do not change.
- Keep transactions short and handle locking of concurrent access.
- Automate backups and test a restore.
✗ Common pitfalls
- Believing that switching to C/S forces a complete rewrite.
- Leaving Classic on a network share with many users.
- Backing up without ever testing the restore.
Key takeaways
- In Client/Serveur mode, a server centralizes the data and returns only the results: performance, robustness, security and remote access.
- Migration changes neither the analysis nor the H code: the work concerns installation, data and the connection.
- Transactions (all or nothing) and locking (concurrent access) guarantee consistency.
- ⚠️ A server requires real administration: monitoring, rights, updates and tested backups.
48h challenge — apply it tomorrow
Like Yacine, take stock of your application: how many simultaneous users, what volumes, what slowdowns? If there is a signal to switch, install a test HFSQL server, migrate a copy of the data and configure the connection. Then wrap a composite operation (order + lines + stock) in a short transaction and force an error to verify that no partial write remains. Finish with a restored backup on a test machine.
- I know when to move from HFSQL Classic to Client/Serveur.
- I install the server, migrate the data and configure the connection.
- I use transactions and locking, with tested backups.
Frequently asked questions
When should you move from HFSQL Classic to HFSQL Client/Serveur?
Switch to Client/Serveur as soon as several users work simultaneously and intensively (criterion no. 1), when volumes grow, when you need fine-grained security or remote access — Classic remains perfect on a single workstation or for a few lightly used workstations. The signals: growing slowdowns at peak hours, corruption incidents, need for per-user rights or encryption, teleworking. Good news for migration: the analysis does not change and the WLangage code remains very largely identical. You install the server, migrate the data and update the connection settings.
Why are transactions essential in multi-user mode?
Because a business operation often involves several writes that must succeed together. Saving an order means creating the header, creating the lines, decrementing stock and updating the customer total: four writes for a single operation. Without a transaction, a failure or outage after the second write leaves an order without lines or stock decremented without an order — a silent inconsistency, discovered weeks later. The transaction guarantees all or nothing: you open it, write, then commit or roll back. It also manages isolation between users and works together with locks.
Why are transactions essential in multi-user HFSQL?