Exécuter un fichier SQL en entier

Tes requêtes fonctionnent quand tu les sélectionnes une par une. Pourtant, le fichier complet échoue sur une note collée entre deux requêtes. Pour livrer ton travail, contrôle aussi ce qu'une autre personne exécutera : tout le fichier, depuis le début. Cette fiche travaille l'exécution reproductible d'une extraction dans le parcours SQL.

Commence par la ligne qui correspond à ton problème. Si tu lis depuis plus de vingt minutes sans avoir essayé la manipulation de cette section, ferme la fiche, retourne à ton fichier et exécute cette manipulation.

1. Réparer un petit fichier

Copie ceci dans un nouveau fichier essai-script.sql, séparé de ton TP. Il doit afficher deux repères, puis trois identifiants de vendeurs. Repère les deux obstacles avant de lancer le fichier entier dans ton éditeur SQL.

SELECT 'debut' AS etape;
Liste des vendeurs
SELECT 'extrait' AS etape
SELECT seller_id FROM sellers ORDER BY seller_id LIMIT 3;

Si tu bloques, cherche ce qui n'est pas du SQL, puis la frontière entre les deux dernières instructions. Un retour à la ligne ne termine pas une instruction.

SELECT 'debut' AS etape;
-- Liste des vendeurs
SELECT 'extrait' AS etape;
SELECT seller_id FROM sellers ORDER BY seller_id LIMIT 3;

Relance maintenant ta correction depuis le début, sans sélection. Vérifie les messages de chaque instruction. Selon l'éditeur, plusieurs résultats peuvent apparaître dans des panneaux distincts : le dernier tableau seul ne prouve pas que le début du fichier a réussi.

2. Vérifier que l'exécution s'arrête sur une erreur

Le client est le logiciel qui envoie ton SQL à PostgreSQL. psql est son client en ligne de commande. Cette section sert si ton éditeur affiche encore des résultats après une erreur, ou si tu dois prouver qu'un contrôle automatique s'arrête au premier échec.

Dans un nouveau fichier verifier-poursuite.sql, copie cette expérience sans l’encadrer par BEGIN et COMMIT, qui regroupent des instructions dans une transaction :

SELECT 'avant' AS etape;
SELECT colonne_absente FROM (SELECT 1) AS exemple;
SELECT 'apres' AS etape;

La deuxième instruction échoue volontairement : la colonne n'existe pas. Prédis si apres sera affiché avec chacune des commandes suivantes, puis compare les messages. Utilise tes paramètres habituels de connexion à la base Olist ; ici, -U olist -d olist désigne le compte et la base d'une installation locale.

psql -X -U olist -d olist -v ON_ERROR_STOP=0 -f verifier-poursuite.sql
psql -X -U olist -d olist -v ON_ERROR_STOP=1 -f verifier-poursuite.sql

Pour contrôler ton fichier corrigé, garde l'arrêt sur erreur :

psql -X -U olist -d olist -v ON_ERROR_STOP=1 -f essai-script.sql

Le contrôle attendu est : aucune erreur SQL, les résultats attendus présents et un code de sortie 0. Si ton outil choisit de continuer après une erreur, il doit quand même signaler l'échec du contrôle. Répare la première erreur, puis relance le fichier complet : une seconde erreur peut avoir été masquée par la première.

3. Un nom de colonne à suivre jusqu'au résultat

Exécute ce bloc. L'erreur est attendue : retrouve le nom défini par AS et celui demandé ensuite.

WITH total AS (SELECT COUNT(*) AS n_tot FROM sellers)
SELECT (SELECT n FROM total);

Une CTE est une requête nommée avec WITH. Ici, elle s'appelle total et sa colonne s'appelle n_tot. PostgreSQL signale que n n'existe pas. Corrige le nom dans le bac à sable, exécute à nouveau et explique pourquoi changer uniquement le nom de la CTE ne réglerait pas l'erreur.

4. Lire la base et reproduire un résultat

Pour examiner les identifiants de sellers, n'ajoute pas une contrainte UNIQUE avec ALTER TABLE. Cette commande modifierait une table partagée si elle réussissait. Un refus peut venir des droits du compte : il ne prouve pas à lui seul la présence de doublons.

Ce contrôle reste en lecture seule et sépare les valeurs absentes des répétitions :

SELECT COUNT(*) - COUNT(seller_id) AS identifiants_absents,
       COUNT(seller_id) - COUNT(DISTINCT seller_id) AS repetitions_non_nulles
FROM sellers;

COUNT(seller_id) ignore les NULL, c'est-à-dire les valeurs absentes. repetitions_non_nulles compte les lignes au-delà de la première occurrence de chaque identifiant renseigné. Ce n'est pas le nombre d'identifiants différents qui se répètent. Une contrainte UNIQUE ordinaire de PostgreSQL peut accepter plusieurs NULL : présence et unicité sont deux contrôles distincts. Voir les contraintes d'unicité PostgreSQL.

Lecture seule ne veut pas dire résultat identique. now() dépend de l'heure de début de la transaction et random() produit un nombre aléatoire. Sans ORDER BY, l'ordre des lignes n'est pas garanti ; avec LIMIT, les lignes retenues peuvent aussi changer. Pour comparer deux exécutions, garde les mêmes données, filtres et paramètres, et un tri qui départage les lignes si leur ordre compte. Si la source a changé, documente sa version ou la date d'extraction au lieu de conclure immédiatement que le script est faux.

Dans le fichier d'analyse, utilise les requêtes de lecture prévues pour le travail. Une correction de données ou de structure se discute et se prépare séparément ; la rejouer n'est pas un contrôle de lecture.

5. Transférer le contrôle à ton fichier

Choisis un fichier SQL de ton dépôt, différent du petit essai. Sans copier le modèle ci-dessus, prépare-le pour une personne qui ne connaît pas tes clics : commentaires identifiables, instructions terminées, noms de colonnes cohérents. Lance-le entier, depuis une nouvelle connexion, puis une seconde fois sur les mêmes données.

Conserve la commande utilisée, ou le geste qui lance tout le fichier dans ton éditeur, ainsi que les messages affichés. Si ton outil fournit un code de sortie, conserve-le aussi. Compare les résultats qui doivent être stables. Si tu as corrigé une ligne, explique en une phrase ce qu'elle empêchait. Si rien n'a échoué, indique tout de même comment tu as contrôlé le fichier entier. Ce test vérifie son exécution ; il reste ensuite à expliquer ce que tes résultats permettent d'affirmer.

Avant de pousser ton travail, vérifie ces quatre traces :

• le fichier a été lancé sans sélectionner une requête isolée ;
• la première erreur éventuelle a été corrigée, puis le fichier entier relancé ;
• le dernier essai ne contient aucune erreur et, si tu as utilisé une commande, son code de sortie vaut 0 ;
• les résultats attendus sont présents, avec le même périmètre et les mêmes données lors des deux exécutions.