Quiz du niveau 2 — Intermédiaire : données, requêtes & états

Quiz — Niveau 2 · Intermédiaire : données, requêtes & états

5 questions, une seule bonne réponse par question.
Répondez à tout, puis cliquez sur Corriger mes réponses : score et explications s'affichent.

1. Quelle est la différence entre HFSQL Classic et Client/Serveur ?

Aucune, ce sont deux noms du même mode CLASSIC : les données sont des FICHIERS sur disque local ou partage réseau, accédés directement (simple, gratuit, monoposte ou petit réseau). CLIENT/SERVEUR : un vrai SERVEUR traite les requêtes et ne renvoie que les résultats (multi-utilisateurs, volumes, sécurité, accès distants) Classic est payant, Client/Serveur gratuit Client/Serveur ne gère pas le SQL

Basculez en Client/Serveur dès qu'apparaissent : plusieurs utilisateurs simultanés intensifs, lenteurs croissantes, gros volumes, besoin de sécurité fine ou d'accès distants. Bonne nouvelle : l'analyse et le code WLangage restent très largement identiques. Les INDEX sont l'optimisation la plus rentable.

2. Pourquoi faut-il filtrer côté BASE plutôt que ramener toutes les données ?

C'est équivalent en performance Parce que le moteur utilise ses INDEX et ne transmet que les lignes utiles, alors que tout ramener sature le réseau et la mémoire pour finalement jeter la majorité des données — l'erreur de performance la plus courante Pour économiser du code Parce que le WLangage ne sait pas trier

Ce défaut est traître : l'application paraît rapide sur le petit jeu de test du développeur, puis devient inutilisable en production. Mettez les conditions dans la requête (WHERE), faites TRIER par la base (ORDER BY), déléguez les agrégats (SUM/COUNT/AVG avec GROUP BY) et vérifiez les INDEX.

3. Comment obtient-on des sous-totaux par groupe dans un ÉTAT ?

En les calculant à la main après impression Avec les RUPTURES : un regroupement sur une rubrique crée un bloc de DÉBUT (titre du groupe) et un bloc de FIN de rupture où se placent les SOUS-TOTAUX — à condition IMPÉRATIVE que les données soient TRIÉES sur cette rubrique En ajoutant une colonne au fichier Les états ne calculent pas de totaux

Sans tri, un même groupe réapparaît plus loin et produit des sous-totaux faux — c'est l'erreur la plus fréquente, et son symptôme est un groupe affiché plusieurs fois. Un état se découpe en BLOCS (début de document, haut de page, CORPS répété par enregistrement, bas de page, fin de document).

4. Quelle différence entre une table FICHIER et une table MÉMOIRE ?

Aucune différence pratique La table FICHIER est LIÉE à un fichier ou une requête et ne charge QUE les lignes affichées (performante même sur de très gros volumes) ; la table MÉMOIRE est remplie par CODE et charge TOUT en mémoire (liberté totale mais inadaptée aux gros volumes) La table mémoire est toujours plus rapide La table fichier ne peut pas être triée

Réflexe par défaut en gestion : dès que les données viennent de la base, utilisez une table FICHIER (basée sur une REQUÊTE si vous devez filtrer ou joindre). Le piège classique est de remplir une table mémoire en parcourant un gros fichier : l'application se fige, et le défaut n'apparaît qu'en production.

5. Pourquoi ne faut-il pas écrire toute la logique métier dans le clic d'un bouton ?

Cela ralentit l'affichage Parce que ce code n'est ni RÉUTILISABLE (la même règle sert dans d'autres écrans, états, imports), ni TESTABLE, ni maintenable — l'événement doit ORCHESTRER et déléguer à des PROCÉDURES nommées Les boutons ont une limite de lignes Il faut tout mettre dans l'analyse

WinDev fonctionne par ÉVÉNEMENTS (déclarations globales, initialisation, clic, entrée/sortie de champ, modification). Placez chaque traitement au bon endroit : un contrôle de saisie va dans la SORTIE du champ, pas dans le bouton Valider. ⚠️ Méfiez-vous des effets en cascade.

Passer au niveau 3Retour au sommaire du guide