IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

SQL Procédural MySQL Discussion :

SOURCE dans un fichier .sql


Sujet :

SQL Procédural MySQL

  1. #1
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 801
    Points : 34 063
    Points
    34 063
    Billets dans le blog
    14
    Par défaut SOURCE dans un fichier .sql
    Bonjour,

    En guise de patches pour mes BDD, j'exécute des fichiers .sql.

    Je viens de découvrir BEGIN NOT ATOMIC qui me permet de mieux contrôler mes scripts DML. Exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    DELIMITER //
    BEGIN NOT ATOMIC
    	DECLARE EXIT HANDLER FOR SQLEXCEPTION
    	BEGIN
    		ROLLBACK;
    		RESIGNAL;
    	END;
     
    	START TRANSACTION;
     
    	SELECT 'INE en minuscules' AS 'Traitement :';
     
    	UPDATE th_etudiant_etu
    	SET etu_ine = LOWER(etu_ine);
     
    	SELECT 'Suppression utilisateurs obsolètes' AS 'Traitement :';
     
    	DELETE FROM th_utilisateur_uti
    	WHERE uti_login IN ('des', 'utilisateurs', 'a_suprrimer');
     
    	SELECT 'Enregistrement du patch' AS Admin;
     
    	INSERT INTO pef.ts_database_admin_dba (dba_nom, dba_nature, dba_commande)
    	VALUES ('plemenager', 'Patch DML', 'PEF_DML_2021-01-20');
     
    	UPDATE pef.ts_database_info_dbi
    	SET dbi_valeur = 'PEF_DML_2021-01-20'
    	WHERE dbi_libelle = 'Dernier SQL diff.';
     
    	COMMIT;
    END;
    //
    Cette méthode permet d'éviter que le script s'exécute à moitié ou que des requêtes suivant une erreur s'exécutent et risquent de provoquer une incohérence de données.
    Malheureursement, le ROLLBACK ne fonctionne que pour les DML mais pas pour les DDL.

    Pour les DDL, quand j'ajoute une table, j'utilise la commande SOURCE dans mes scripts de patches :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    	SELECT 'Ajout table des spécificités de la candidature IFSE' AS 'Traitement :';
     
    	SOURCE ../Tables/th_candidature_ifse_cif.sql;
    Ça fonctionne très bien depuis longtemps mais j'ai essayé d'appliquer la méthode de contrôle de la bonne exécution des DML aux DDL :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    DELIMITER //
    BEGIN NOT ATOMIC
    	DECLARE EXIT HANDLER FOR SQLEXCEPTION
    	BEGIN
    		ROLLBACK;
     
    		-- Suppression des modifs du patch en cas d'erreur
    		DROP TABLE IF EXISTS th_candidature_ifse_cif;
     
    		ALTER TABLE te_experience_professionnelle_exp
    		DROP COLUMN IF EXISTS exp_precision_statut_pro;
     
    		RESIGNAL;
    	END;
     
    	SELECT 'Ajout table des spécificités de la candidature IFSE' AS 'Traitement :';
     
    	SOURCE ../Tables/th_candidature_ifse_cif.sql;
     
    	SELECT 'Ajout colonne satatut pro à préciser dans te_experience_professionnelle_exp' AS 'Traitement :';
     
    	ALTER TABLE te_experience_professionnelle_exp
    	ADD COLUMN exp_precision_statut_pro TEXT 
    		NOT NULL 
    		DEFAULT '' 
    		COMMENT 'Précision sur le statut professionnel';
     
    	SELECT 'Enregistrement du patch' AS 'Traitement : ';
     
    	INSERT INTO pef_public.ts_database_admin_dba (dba_nom, dba_nature, dba_commande)
    	VALUES ('plemenager', 'Patch DDL', 'PFP_DDL_2021-01-19');
     
    	UPDATE pef_public.ts_database_info_dbi
    	SET dbi_valeur = 'PFP_DDL_2021-01-19'
    	WHERE dbi_libelle = 'Dernier SQL diff.';
     
    END;
    //
    Et à l'exécution, j'ai une belle erreur de syntaxe :
    ERROR 1064 (42000) at line 9 in file: 'DDL/PFP_DDL_2021-01-19.sql': You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '../Tables/th_candidature_ifse_cif.sql;
    On dirait que la commande SOURCE ne soit pas acceptée dans ce contexte.

    Une idée à me soumettre ?

  2. #2
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 353
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 353
    Points : 39 764
    Points
    39 764
    Billets dans le blog
    9
    Par défaut
    Bonjour Philippe

    As tu essayé d'externaliser le DDL dans une UDF qui contiendrait cette commande SOURCE ?

  3. #3
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 801
    Points : 34 063
    Points
    34 063
    Billets dans le blog
    14
    Par défaut
    Non.

    Typiquement, j'exécute via la commande mysql :
    Code bash : Sélectionner tout - Visualiser dans une fenêtre à part
    mysql -u mon_user - p < mon_patch.sql

    Ce fichier de patch général contient lui-même des instructions SOURCE vers de patches par catégorie :
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    SOURCE DDL/mon_patch_DDL.sql;
    SOURCE DML/mon_patch_DML.sql;

    Et le dossier Tables est au même niveau que le dossier Patches à partir duquel est lancé la commande mysql, donc un niveau au dessus du dossier où se situe mon_patch_DDL.sql
    Patches
    - DDL
    -- mon_patch_DDL.sql
    - DML
    -- mon_patch_DML.sql
    Tables
    - th_candidature_ifse_cif.sql

    Sans l'encapsulation dans le BEGIN NOT ATOMIC, ce système fonctionne très bien mais je souhaite l'encapsuler pour revenir en arrière en cas d'erreur.

  4. #4
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 801
    Points : 34 063
    Points
    34 063
    Billets dans le blog
    14
    Par défaut
    En mettant directement le script de création de la table, ça passe. Donc c'est bien la commande SOURCE qui pose problème.

  5. #5
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 801
    Points : 34 063
    Points
    34 063
    Billets dans le blog
    14
    Par défaut
    La commande source est autorisé dans un script sql.
    Mais elle est interdite dans un bloc définie par "begin ... end" ou dans une procédure stockée.
    Cette réponse là aurait suffi !

    Comme dit précédemment, la commande source ne fonctionne pas dans votre contexte.

    --> en dehors des procédures stockées

    Il est dit que tout ce que l'on peut mettre dans une procédure stockée est autorisée. Sauf que la commande source ne l'est pas.

    Il y a un truc que je ne comprends pas dans votre exemple.
    Il s'agit d'une part de l'utilisation de "BEGIN NOT ATOMIC" et d'autre part la commande "START TRANSACTION".

    --> bloc begin ... end

    Le simple BEGIN sert à démarrer une transaction. C'est historique !
    Si vous désirez utiliser un bloc sans transaction, il faut utiliser "BEGIN NOT ATOMIC".
    Ça c'est intéressant aussi et me donne une piste à explorer.
    Le reste est à côté de la plaque ! Il aurait fallu me lire correctement. L'objet est justement l'utilisation de BEGIN NOT ATOMIC que je viens de découvrir.

    Bref... merci quand même pour la réponse même si j'ai souvent l'impression que vous répondez au fur et à mesure de la lecture au lieu de lire d'abord pour comprendre le sens global avant de construire votre réponse.

  6. #6
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 485
    Points : 19 517
    Points
    19 517
    Par défaut
    Salut CinePhil.

    Citation Envoyé par CinePhil
    même si j'ai souvent l'impression que vous répondez au fur et à mesure de la lecture
    C'est ce que je fais. Je réponds aux questions au fur et à mesure de mes lecture, afin de ne rien oublier.
    Je prends quand même le temps de faire des recherche et de réfléchir à ce que je vais dire, au cas où vous ne l'auriez pas constaté.

    Citation Envoyé par CinePhil
    Le reste est à côté de la plaque !
    Pas du tout.

    Votre exemple gère bien une grappe de données que vous validez ou que vous rejetez.
    Je retrouve la structure de ce qu'il faut faire afin de ne pas avoir un problème d'intégrité des données.
    Puisque votre exemple est opérationnel pourquoi la modifier ?

    Citation Envoyé par CinePhil
    Il aurait fallu me lire correctement.
    C'est ce que j'ai fait. Désolé si ma réponse ne vous satisfait pas.

    Citation Envoyé par CinePhil
    L'objet est justement l'utilisation de BEGIN NOT ATOMIC que je viens de découvrir.
    Pourquoi ne pas l'avoir dit dès le début ? Votre question concernait la commande "source" et non le "BEGIN NOT ATOMIC".

    Le BEGIN NOT ATOMIC est un bloc qui ne débute pas par une transaction, comme le fait le BEGIN.
    Après quelques recherches, je n'ai pas trouvé grand chose à ce sujet.

    @+

  7. #7
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 801
    Points : 34 063
    Points
    34 063
    Billets dans le blog
    14
    Par défaut
    Pour que la description de mon problème soit plus clair...

    AVANT ma découverte du BEGIN NOT ATOMIC, mes patches étaient constitués de fichiers .sql, en séparant les fichiers pour le code (vues, procédures...), le DDL (ALTER), et le DML (INSERT, UPDATE, DELETE). Mes tables, vues et procédures font l'objet chacune d'un fichier .sql.

    Lorsque je créais une vue ou une procédure, j'insérais dans un patch code les appels aux fichiers .sql correspondants.
    Exemple fictif :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    -- Patch COD_2021-01-10
    SELECT 'Ajout de la vue v_machin' AS 'Traitement :';
    SOURCE ../Vues/v_machin.sql;
    Lorsque je créais une table, j'insérais dans un patch DDL les appels aux fichiers .sql correspondants.
    Exemple fictif :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    -- Patch DDL_2021-01-05
    SELECT 'Ajout de la table te_truc_tru' AS 'Traitement :';
    SOURCE ../Tables/te_truc_tru.sql;
    Tous mes patches terminent par un enregistrement du patch dans une table d'administration de la BDD.

    Si la vue v_machin utilise la table te_truc_tru, il faut s'assurer que le patch DDL_2021-01-05 a bien été passé avant le patch COD_2021-01-10. J'ai pour ça une procédure qui interroge la table d'administration et qui lève une erreur en cas d'absence du patch souhaité.

    Le problème était qu'une éventuelle erreur donnée par la procédure de contrôle ou lors de l'exécution d'une des requêtes du patch n'interrompait pas celui-ci.
    Exemple fictif :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    -- Patch DDL_2021-01-12
    SELECT 'Ajout table te_bidule_bid' AS 'Traitement :';
    SOURCE ../Table/te_bidule_bid.sql;
     
    SELECT 'Ajout colonne à te_truc_tru' AS 'Traitement :';
    ALTER TABLE te_truc_tru
    ADD COLUMN tru_id_bidule INTEGER NOT NULL COMMENT 'Identifiant du bidule associé au truc',
    ADD CONSTRAINT fk_tru_id_bidule
        FOREIGN KEY (tru_id_bidule)
        REFERENCES te_bidule_bid (bid_id)
        ON DELETE CASCADE
        ON UPDATE CASCADE;
     
    SELECT 'Enregistrement du patch' AS 'Traitement :';
    INSERT INTO ta_admin_bdd_abd (abd_patch, abd_date)
    VALUES ('DDL_2021-01-02', CURRENT_DATE);
    Si la création de la table plante, l'ajout de colonne essaiera de se faire (et plantera aussi puisque la table de référence n'existe pas) et le patch s'enregistrera quand même dans la table d'administration.

    J'espérais pouvoir utiliser le BEGIN NOT ATOMIC pour mieux contrôler l'exécution globale du patch ou déclencher, grâce à un handler d'erreur, l'annulation de ce qui avait déjà été éventuellement créé par le patch en cas d'erreur,

    J'ai mis cette méthode en oeuvre avec succès dans le cas des patches DML mais ce n'est pas possible dans le cas des patches qui contiennent la commande SOURCE et je cherche donc une autre solution.
    Pour le moment, celle que j'ai trouvée consiste à mettre le code normalement appelé par la commande source directement dans le patch.

  8. #8
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 485
    Points : 19 517
    Points
    19 517
    Par défaut
    Salut CinePhil.

    J'ai installé MariaDB version 10.5.8 et j'ai fait quelques tests.

    Voici quelques remarques :

    1) source ne peut pas être utilisé au sein de "BEGIN NOT ATOMIC". Ni d'ailleurs dans une procédure stockée.

    2) il existe des validations implicites qui ne peuvent pas être défaites par un rollback : create, alter, drop, truncate, ...
    Voire ce lien pour le détail.

    Il y a aussi le "SET AUTOCOMMIT=1" qui provoque une validation implicite.

    Il y a des exceptions à cela, comme le "create temporary table ..." ou le "drop temporary table ..."

    3) par contre les validations explicites sont défaites par un rollback.
    Tout ce qui est "DML" peut être défait par un rollback.
    Inversement, presque tout ce qui est "DDL" ne peut pas être défait par un rollback.

    J'ai constaté la même chose sous mysql.

    4) on peut utiliser un "SAVEPOINT" comme point de reprise (ou de sauvegarde).
    Mais bon, cela n'apporte pas grand chose à ta problématique.

    5) j'ai fait quelques simulations en reprenant les mêmes idées.
    J'ai constaté les mêmes problèmes sans pouvoir, dans ce contexte, apporter quoi que ce soit de nouveau.

    6) une précision : si au début de ton script, tu utilises un "delimiter ||", il faut en faire un autre à la fin "delimiter ;".

    7) pour ce qui est du "DDL", dans la partie "DECLARE exit HANDLE ..", il faut défaire, tout ce qui a été fait dans le corps du traitement.
    C'est lourd et c'est la seule façon de procéder dans ce contexte, à cause des validations implicites.

    8) en ce qui me concerne, je pense que ton approche de modifier ta modélisation par des patches, n'est pas la bonne solution.
    J'utiliserai plutôt l'export en passant par mysqldump qui selon moi, est mieux adapté à cela.

    9) quelle est la raison de tous ces patches ?
    As-tu beaucoup de modifications à faire dans tes serveurs MariaDB ?

    10) as-tu des tests à me soumettre, voire des pistes d'amélioration à faire ?

    @+

  9. #9
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 801
    Points : 34 063
    Points
    34 063
    Billets dans le blog
    14
    Par défaut
    8) en ce qui me concerne, je pense que ton approche de modifier ta modélisation par des patches, n'est pas la bonne solution.
    J'utiliserai plutôt l'export en passant par mysqldump qui selon moi, est mieux adapté à cela.
    Je ne comprends pas bien comment mysqldump pourrait m'aider...
    En ne dumpant que la table à modifier sur la BDD de développement et en la rechargeant sur le serveur de prod ?
    => Dangereux pour les données de prod, ça, non ?

    9) quelle est la raison de tous ces patches ?
    As-tu beaucoup de modifications à faire dans tes serveurs MariaDB ?
    Nous sommes en développement à 2 développeurs et une première version partielle des applications a été livrée en prod.

    En gros :
    - 2 applications : une publique pour les candidats / étudiants et une privée pour l'administration de la vie scolaire ;
    - 3 bases de données : une pour les données de référence (pays, types, statuts, diplômes...), une pour l'application publique et une pour l'application privée.

    L'application globale comprendra de nouveaux modules pas encore développés. Ces modules apporteront leur lot de tables supplémentaires et, peut-être, voire probablement, des modifications de structure dans certaines tables existantes. On s'occupe pour le moment de la gestion des étudiants mais nous aurons aussi la gestion des stagiaires... dont certains sont aussi étudiants (profs en poste préparant un master MEEF dans le cadre de leur formation continue).

    Donc oui, il y a des modifications de structure de temps en temps qui finissent par être poussées sur les serveurs de prod.

    10) as-tu des tests à me soumettre, voire des pistes d'amélioration à faire ?
    Des tests, non.
    Mais grosso-modo, la méthode que j'ai déja décrite plus haut est que :
    1) un patch global (par exemple pour la BDD référentiel nommé REF_2021-01-25.sql) fait appel à un à plusieurs patches secondaires (ex. REF_DDL_2021-01-25.sql + REF_DML_2021-01-25.sql) à l'aide d'instructions SOURCE.
    2) dans les patches DML, le BEGIN NOT ATOMIC et le HANDLER d'erreur permet de rollback en cas de plantage à l'exécution du patch.
    3) j'aimerais avoir un système équivalent pour le DDL. Le SOURCE étant inutilisable dans une structure BEGIN END, la seule solution pour le moment est de mettre directement le code CREATE TABLE dans le patch DDL alors que j'ai déjà un fichier nom_table.sql par ailleurs. C'est dommage !

    Question subsidiaire :
    Nous avions envisagé de faire une réplication entre la BDD referentiel du serveur privé vers la même BDD du serveur public mais par manque de temps, je n'ai pas étudié cette possibilité à fond et nous exécutons finalement les patches sur les deux serveurs.

    Si la réplication est mise en oeuvre, prend-elle en compte les modifications DDL ou seulement le DML ? Et pour les procédures et vues (patches de code) ?

  10. #10
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 485
    Points : 19 517
    Points
    19 517
    Par défaut
    Salut CinePhil.

    Citation Envoyé par CinePhil
    Je ne comprends pas bien comment mysqldump pourrait m'aider...
    Ton problème est que tu interviens directement en production.
    On ne bidouille jamais en production. C'est une règle !!!
    On passe par différents environnements avant de faire une livraison définitive en production.

    Je viens du monde des grands comptes bancaires, gros système IBM, où il est habituel d'avoir plusieurs environnements, comme :
    --> production
    --> préproduction pour faire des tests. C'est en général la production de la veille (j-1).
    --> intégration dans l'existant. On test les compatibilités, les performances, les outils ...
    --> fonctionnelle pour le respect de ce qui a été demandé dans le projet.
    --> technique qui sert surtout à faire deux choses : des livraisons et des tests techniques.
    --> développement pour chaque développeur où il fait sa compilation et ses propres tests.

    Chaque environnement est une nouvelle version.
    Quand elle est validée par des tests, elle passe à l'étape supérieure, et ainsi de suite jusqu'à la production.

    Citation Envoyé par CinePhil
    => Dangereux pour les données de prod, ça, non ?
    Dans ta façon de travailler, oui, c'est dangereux. Pourquoi ?

    a) en principe, la production fonctionne 24h/24h. D'où son intérêt d'être opérationnelle.

    b) on ne bidouille jamais en production car sans le faire exprès, on peut casser quelque chose.
    Cela peut provoquer un plantage, voire un problème dans l'intégrité des données si tu livres deux version différentes en même temps.
    Ce qui revient à dire que la production n'est plus opérationnelle.

    c) livrer quelque chose sans l'avoir soumis à des tests aupréalable.
    Cela peut être une erreur fonctionnelle, un problème d'intégration, quelque chose de mal compris, un oubli dans une livraison, ...
    Si tu es en production, tu fais comment pour revenir en arrière ? Tu perds une journée !

    d) je parles même pas du temps perdu, au niveau de la saisie, quand tu dois revenir en arrière, car tu dois tout recommencer.
    D'où perte de temps !

    Il vaut mieux respecter une monté en puissance en gérant chaque livraison, comme une nouvelle version.
    Et bien sûr, faire des tests, toujours des tests.
    Si tu oublies quelques choses, ce n'est pas grave car tu es encore dans une phase de test.
    Quand la phase est terminée, tu passes à l'environnement supérieur et ainsi de suite, jusqu'à la production.

    Désolé de dire, mais c'était ma façon de travailler.

    Citation Envoyé par CinePhil
    Ces modules apporteront leur lot de tables supplémentaires et, peut-être, voire probablement, des modifications de structure dans certaines tables existantes.
    Comment es tu certain que tes modifications sont conformes à ce que tu attends ?
    Il y a toujours un oubli, voire une erreur involontaire, quelque chose de mal compris.
    Tu ne peux pas maitriser la totalité de ton projet sans faire des tests.
    D'où l'intérêt des différents environnements !

    As-tu prévu une gestion par version ?

    J'espère aussi que tu fais des sauvegardes quotidiennes de la production.

    Citation Envoyé par CinePhil
    Donc oui, il y a des modifications de structure de temps en temps qui finissent par être poussées sur les serveurs de prod.
    L'intérêt de la pré-pro, sert à tester en réel, avant de faire une livraison définitive à la production.
    Il arrive que le jeu d'essai que tu utilises, ne soit pas conforme à la réalité.
    Si tu as des garde-fous, cela va sécuriser tes livraison et donc tes versions.

    L'idée à mettre en œuvre ? Je ne peux pas répondre facilement car cela dépend de beaucoup de choses, comme :
    1) votre façon de travailler.
    2) vos dates de livraison.
    3) la volumétrie.
    4) l'impact sur l'existant.
    5) des tests à faire aupréalable avant la mise en production.

    L'impact n'est pas le même s'il s'agit de modifier ponctuellement une table ou si cela concerne plusieurs tables et plusieurs programmes.

    Tu l'auras compris, je crée des environnements, et je fais des tests et je gère des versions.
    Une livraison de la version N vient écraser la version N-1.
    Tu peux te permettre de bidouiller dans un environnement, sauf pre-pro et production.

    Citation Envoyé par CinePhil
    une première version partielle des applications a été livrée en prod.
    Dois-je comprendre que la première livraison en prod, correspond à la première phase de votre projet, qui est une phase stable.

    Citation Envoyé par CinePhil
    Mais grosso-modo, la méthode que j'ai déjà décrite plus haut est que :
    cela fonctionne parfaitement pour le DML mais pas pour le DDL.

    Citation Envoyé par CinePhil
    j'aimerais avoir un système équivalent pour le DDL.
    Il n'y a rien d'équivalent car cela n'a jamais été prévu de faire évoluer une base de données par des patches.

    Citation Envoyé par CinePhil
    C'est dommage !
    C'est une contrainte et il faut faire avec. C'est cela les plaisirs de l'informatique.

    Citation Envoyé par CinePhil
    Si la réplication est mise en œuvre, prend-elle en compte les modifications DDL ou seulement le DML ?
    Bonne question. La réplication a été mise en œuvre pour les données.

    Oui, on peut faire de la réplication DDL. Mais il faut se donner les droits pour le faire.
    Si une base de données est inexistante, tu peux la créer dans le master, et elle sera dupliquée dans le slave.

    En ce qui me concerne, je n'ai fait que de la réplication master/slave.

    @+

  11. #11
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 353
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 353
    Points : 39 764
    Points
    39 764
    Billets dans le blog
    9
    Par défaut
    Bonjour

    Citation Envoyé par Artemus24 Voir le message
    Ton problème est que tu interviens directement en production.
    On ne bidouille jamais en production. C'est une règle !!!

    On passe par différents environnements avant de faire une livraison définitive en production.
    De ce que je comprends, il n'y a aucune bidouille : le même script DDL sert à déployer les objets sur les différents environnements.
    Chaque évolution du DDL fait l'objet d'une génération de version
    C'est une démarche assez classique que j'ai rencontrée chez de nombreux clients.
    Je ne vois rien à y redire.

  12. #12
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 801
    Points : 34 063
    Points
    34 063
    Billets dans le blog
    14
    Par défaut
    Exactement escartefigue !

    1) Chaque patch est créé sur ma machine de développement et testé sur ma BDD de ma machine.
    2) Si c'est bon sur ma machine, git pull vers le dépôt du serveur de développement.
    3) Passage du patch sur la BDD du serveur de développement.
    4) Si c'est bon et après qu'on soit d'accord avec ma collègue (développements PHP liés nécessaires par exemple), passage du patch sur le serveur de prod.

    Et pour autre exemple, je viens de faire une mise à jour d'une BDD Oracle qui sert à notre ERP selon le même principe :
    1) Je reçois des annonces de publication de patch par le fournisseur de l'ERP.
    2) Je teste le passage des patches sur une BDD de test qui a été rechargée à partir de la production.
    3) Si c'est bon et s'il n'y a pas de messages inquiétants relevant des bugs sur le forum des responsables de l'ERP des les établissements clients, je fais la mise à jour en prod le dernier mercredi du mois après avoir arrêté les applications.

    C'est d'ailleurs le système de patch de la BDD Oracle venant du fournisseur de notre ERP qui m'a donné l'idée d'en faire un similaire pour nos développements internes.

    Bref, non, je ne fais pas n'importe quoi avec la prod !

  13. #13
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 485
    Points : 19 517
    Points
    19 517
    Par défaut
    Salut à tous.

    Je vais prendre l'exemple de mon site qui est hébergé chez AlwaysData.

    En premier lieu, j'ai l'exacte réplique de ce qui est hébergé sur mon ordinateur.

    Mon site web est découpé en 19 répertoires. Chaque répertoire contient l'intégralité d'un thème.
    Soit un ensemble de documents html/php, des fichiers css, du javascript, des images, des fichiers à charger, ...
    Si je viens à modifier disons une ligne dans un document html, je livre l'ensemble de ce qui se trouve dans le répertoire en question.
    J'ai un batch windows pour chaque répertoire qui réalise le transfert entre mon ordinateur et mon espace de travail chez Alwaysdata.

    Voici comment j'applique mes modifications sur ma base de données :
    1) ce qui est chez l'hébergeur est ma production.
    2) ce qui est sur mon ordinateur est ma pré-prod.
    3) je réalise mes modifications dans ma pré-prod.
    4) Ma pré-prod correspond à une nouvelle version à livrer.
    5) la production correspond à la version N et la pré-prod à la version N+1.
    6) je fais mes tests à partir du déchargement intégrale de la base de données en production, de la veille.
    7) j'ai un script qui réalise la migration des données de l'ancienne vers la nouvelle base.
    8) la migration se fait en deux temps, d'abord la base de données de la veille puis la sauvegarde différentielle du jour.
    9) quand je suis prêt à migrer, je stoppe le serveur, et je récupère la sauvegarde différentielle.
    10) je termine la migration de la nouvelle base de données qui se trouve sur mon ordinateur.
    11) comme mes tests ont validé mes nouvelles modifications, je n'ai jamais de problème quand je migre la différentielle.
    12) et enfin, j'effectue un export de la totalité de la nouvelle base vers la production. Je passe par phpmyadmin.
    13) et pour terminer, je redémarre le serveur.

    Hormis une nouvelle version, j'ai toujours ma production à l'identique de ma pré-prod.
    Depuis que j'utilise cette technique, je n'ai jamais rencontré de problèmes.
    Entre l'arrêt du serveur et son redémarrage, je n'ai jamais dépassé les 15 minutes.
    J'utilise la même technique (la migration) quand je change de version pour le forum de type phpbb.
    Je n'interviens jamais ponctuellement en prod par l'application d'un patch ou quoi qu ce soit d'autre.

    Si par hasard, mon hébergeur venait à supprimer mon compte, je n'ai rien perdu car j'ai ma pré-prod, mais aussi des sauvegardes quotidiennes.
    Si j'ai besoin de vérifier quelque chose, je le fais en pré-prod, quitte à récupérer la sauvegarde de la base de données de la veille.

    C'est la même technique que j'ai utilisée dans les grands comptes du domaine bancaire.
    Cela peut sembler lourd au premier abord, mais quand on livre, on est certain de ne pas avoir de bug.

    Citation Envoyé par Escartefigue
    Chaque évolution du DDL fait l'objet d'une génération de version
    Je suis d'accord avec toi, sauf qu'un patch ne répond pas à cette affirmation.
    Un patch, c'est de la bidouille, même si cette bidouille semble la façon de procéder dans certains entreprises.
    Une migration, c'est la bonne technique. C'est lourd mais cela à fait ses preuves.

    J'ai fait beaucoup de migrations surtout à l'époque où l'on est passé de BULL à IBM.
    Pourquoi n'a-t-on pas utilisé la technique des patchs ?
    Pour la simple raison, qu'il y a trop de modifications à faire aussi bien dans les données que dans les traitements.

    A vrai dire, ce n'est pas le patch qui me dérange.
    Mais le fait d'intervenir directement en production, de faire la modification et de ne pas un test de vérification.

    @+

  14. #14
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 353
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 353
    Points : 39 764
    Points
    39 764
    Billets dans le blog
    9
    Par défaut
    Dans les deux cas, il s'agit d'un circuit court puisqu'il n'y a qu'un seul niveau de test avant la prod.

    Les clients que je pratique ont des circuits plus longs comme par exemple test unitaire ==> intégration ==> recette échantillon ==> recette volume réel ==> pré-prod ==> prod.

    Que le circuit soit plus ou moins long, ce qui compte c'est de ne pas découvrir les sujets une fois en prod, c'est bien le cas dans ce que décrit CinéPhil, donc rien à redire. Bien sûr, un trajet long est plus sécurisant, mais le budget n'est pas toujours là, ni les équipes, ni les délais. Bref, on fait avec ce qu'on a.

    Au sujet des patchs, de nombreux fournisseurs (tous ?) procèdent ainsi, c'est un fonctionnement tout à fait normal : version majeures, mineures et patchs. Si le fournisseur est serieux, le patch l'est aussi.
    Cela étant dit, personne n'est à l'abri de défaillances, les tests sont là pour les déceler.
    Mais jeter a priori l'usage des patchs aux orties c'est jeter en même temps la plupart des fournisseurs à la benne... à commencer par IBM que je connais le mieux et dont le sérieux fait autorité (autant que les prix exorbitants du reste )

  15. #15
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 485
    Points : 19 517
    Points
    19 517
    Par défaut
    Salut à tous.

    Citation Envoyé par Escartefigue
    Les clients que je pratique ont des circuits plus longs comme par exemple test unitaire ==> intégration ==> recette échantillon ==> recette volume réel ==> pré-prod ==> prod.
    Ce sont certainement les mêmes clients que j'ai fréquenté, les grands comptes bancaires et d'assurances.

    Citation Envoyé par Escartefigue
    Que le circuit soit plus ou moins long, ce qui compte c'est de ne pas découvrir les sujets une fois en prod
    La raison est fort simple, un plantage et ce sont des milliers d'euros de perte à cause de l'indisponibilité de la production.
    Serais-tu comptant de ne pas pouvoir accéder à ton compte bancaire 24H/7J ? Idem pour les assurances.
    A chacun son expérience. En ce qui me concerne, j'ai toujours travaillé en SSII dans les banques et parfois dans les assurances.

    Maintenant, je reconnais que les serveurs web sont moins soumis à cette contrainte de disponibilité.
    On peut se permettre d'arrêter le serveur quelques minutes dans une journée dans une période creuse.

    En ce qui concerne ma démarche livraison pour mon site web, elle est soumise aussi au fait que je suis hébergé en mutualisé.
    Je ne peux pas lancer des applications dans mon espace de travail car je risque fort de pénaliser les clients qui sont hébergés sur le même serveur que moi.
    Et puis, si l'hébergeur apprend cela, je risque de me faire virer sans avertissement.
    En effet, il y a des choses que l'on ne peut pas se permettre de faire, même en payant.

    J'ai des outils à ma disposition comme Filezilla FTP pour le transfert vers mon espace de travail.
    Mais je préfère utiliser des outils en ligne de commande, comme "pscp.exe" qui me permet de faire le transfert au travers d'un script.
    Je sais, aujourd'hui, on dit plutôt le cloud qu'un espace de travail.

    Par contre, si j'introduis de nouvelles tables, et/ou de nouveaux répertoires contenant de nouveaux documents html/php, je les transferts directement.
    Mais j'ai bien un environnement pré-prod qui se trouve dans mon ordinateur, à l'identique de ce qui se trouve chez mon hébergeur.

    Combien de fois j'ai vu, un client se faire virer de chez AlwayData et qu'il n'avait même pas fait une sauvegarde de son cloud.
    Il y a bien des sauvegardes automatiques quotidiennes, mais elles sont accessibles que si tu as accès à ton cloud.

    Citation Envoyé par Escartefigue
    Dans les deux cas, il s'agit d'un circuit court puisqu'il n'y a qu'un seul niveau de test avant la prod.
    Circuit court, je veux bien mais encore une fois, mon problème est que je n'ai pas droit de bidouiller directement en production.

    Si CinePhil a le droit de faire cela, c'est le problème de son responsable et c'est à ses risques et périls.

    Citation Envoyé par Escartefigue
    Cela étant dit, personne n'est à l'abri de défaillances, les tests sont là pour les déceler.
    Et comment fais-tu les tests si tu livres directement en production ? A oui, je sais, en production.

    Citation Envoyé par Escartefigue
    Mais jeter a priori l'usage des patchs aux orties c'est jeter en même temps la plupart des fournisseurs à la benne... à commencer par IBM que je connais le mieux et dont le sérieux fait autorité (autant que les prix exorbitants du reste )
    J'ai déjà travaillé avec eux, ce ne sont pas des lumières et je confirme que leur prestation est exorbitante.
    Donc non, je ne suis pas aussi exalté que toi à ce sujet.

    @+

  16. #16
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 801
    Points : 34 063
    Points
    34 063
    Billets dans le blog
    14
    Par défaut
    Au final, voici un exemple de solution adoptée, puisque SOURCE ne peut pas être utilisé dans du code procédural.
    Je commence par créer le handler d'erreur qui :
    - ROLLBACK les éventuelles données modifiées avant l'erreur ;
    - Revient en arrière sur toute la partie DDL du patch.

    Ensuite vient le code actif du patch avec, dans le cas présent :
    - Création d'une table ;
    - Modification d'une colonne ;
    - Ajout d'une colonne ;
    - Enregistrement du patch dans les tables d'information de la BDD.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    /**
     * Patch PEF DDL du 05/05/2021
     * @file : SQL_Pef/Scripts/Patches/DDL/PEF_DDL_2021-05-05.sql
     * @Author : Philippe Leménager
     */
     
    -- Base d'exécution du patch
    USE pef;
     
    DELIMITER //
    BEGIN NOT ATOMIC
    	DECLARE EXIT HANDLER FOR SQLEXCEPTION
    	BEGIN
    		-- Annulation des données éventuellement modifiées par le patch
    		ROLLBACK;
     
    		-- Suppression de la table éventuellement créée par le patch
    		DROP TABLE IF EXISTS ta_log_evenement_lev;
     
    		-- Annulation éventuelle du changement de colonne ins_date_etat
    		ALTER TABLE te_inscription_ins
    		MODIFY ins_date_etat DATE NOT NULL DEFAULT CURRENT_DATE COMMENT 'Date de l''état de l''inscription';
     
    		-- Annulation éventuelle de la création de la colonne uti_date_creation
    		ALTER TABLE th_utilisateur_uti
    		DROP COLUMN uti_date_creation;
     
    		RESIGNAL;
    	END;
     
    	START TRANSACTION;
     
    	SELECT 'Vérification de l''application de patch essentiel' AS 'Vérification';
     
    	CALL referentiel.pa_patch_existe('referentiel', 'REF_DDL_2021-05-05', @res);
    	SELECT @res AS Verif_patch_essentiel;
     
    	SELECT 'Création table administrative de log d''événement' AS 'Création';
     
    	CREATE TABLE IF NOT EXISTS ta_log_evenement_lev
    	(
    		lev_id_utilisateur INTEGER NOT NULL COMMENT 'Identifiant de l''utilisateur',
    		lev_date_heure DATETIME NOT NULL DEFAULT CURRENT TIMESTAMP COMMENT 'Date/heure de l''événement',
    		lev_id_type_evenement TINYINT NOT NULL COMMENT 'Identifiant du type d''événement',
    		lev_changement_valeur VARCHAR(100) NOT NULL DEFAULT '' COMMENT 'Détail du changement de valeur de donnée effectué'
    	)
    	ENGINE=InnoDB 
    	DEFAULT CHARSET=utf8mb4 
    	COMMENT='Trace d''évenements de modification de données';
     
    	-- Index pour la table ta_log_evenement_lev
    	ALTER TABLE ta_log_evenement_lev
    		ADD PRIMARY KEY (lev_id_utilisateur, lev_date_heure),
    		ADD KEY x_lev_id_type_evenement (lev_id_type_evenement),
    		ADD CONSTRAINT fk_lev_id_utilisateur 
    			FOREIGN KEY (lev_id_utilisateur)
    			REFERENCES th_utilisateur_uti (uti_id_personne_physique)
    			ON UPDATE CASCADE
    			ON DELETE CASCADE,
    		ADD CONSTRAINT fk_lev_id_type_evenement 
    			FOREIGN KEY (lev_id_type_evenement)
    			REFERENCES referentiel.tr_type_evenement_tev (tev_id)
    			ON UPDATE CASCADE
    			ON DELETE RESTRICT;
     
    	SELECT 'Modif colonne ins_date_etat de commentaires sur te_inscription_ins' AS Modif;
     
    	ALTER TABLE te_inscription_ins 
    	MODIFY ins_date_etat DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Date de l''état de l''inscription';
     
    	SELECT 'Ajout colonne uti_date_creation dans table th_utilisateur_uti' AS Modif;
     
    	ALTER TABLE th_utilisateur_uti
    	ADD COLUMN uti_date_creation DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Date de création du compte utilisateur';
     
    	SELECT 'Enregistrement du patch' AS 'Traitement';
     
    	INSERT INTO ts_database_admin_dba (dba_nom, dba_nature, dba_commande)
    	VALUES ('plemenager', 'Patch DDL', 'PEF_DDL_2021-05-05');
     
    	UPDATE ts_database_info_dbi
    	SET dbi_valeur = 'PEF_DDL_2021-05-05'
    	WHERE dbi_libelle = 'Dernier SQL diff.';
     
    	COMMIT;
    END;
    //

  17. #17
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 801
    Points : 34 063
    Points
    34 063
    Billets dans le blog
    14
    Par défaut
    Bon ben j'ai encore un souci !

    Comme déjà expliqué plus haut, je lance en ligne de commande un premier fichier .sql :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    mysql -u admin -p < REF_patch_2021-05-05.sql
    Et ce fichier lance successivement deux autres fichiers de patch :
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    /**
     * Patch global du 05/05/2021
     * @file : Referentiel/SQL/Patches/REF_patch_2021-05-05.sql
     * @Author : Philippe Leménager
     */
     
    -- Base d'exécution du patch
    use referentiel;
     
    SELECT 'REF_DDL_2021-05-05' AS Patch;
    SOURCE DDL/REF_DDL_2021-05-05.sql;
     
    SELECT 'REF_DML_2021-05-05' AS Patch;
    SOURCE DML/REF_DML_2021-05-05.sql;
     
     
    SELECT "Patch terminé" AS Resultat;

    Mais comme dans le premier patch DDL (voir code dans mon message précédent) j'ai utilisé la forme procédurale BEGIN NOT ATOMIC il semble que MariaDB considère, malgré la sortie avec COMMIT suivi de END et du DELIMITER, que je sois encore en mode procédural parce qu'au moment de lancer le second patch DML, j'ai une erreur encore sur SOURCE :
    Patch
    REF_DML_2021-05-05
    ERROR 1064 (42000) at line 13: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'SOURCE DML/REF_DML_2021-05-05.sql;
    Donc je ne peux pas enchaîner deux patches à partir du même fichier de lancement.

  18. #18
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 485
    Points : 19 517
    Points
    19 517
    Par défaut
    Salut CinePhil.

    Si l'enchainement de deux sources dans un exécutable mysql posent des problèmes, fait deux exécutables mysql ayant un et un seul source.
    Autrement dit, l'enchainement ne se fait pas dans le script sql, mais dans le script batch windows.

    @+

  19. #19
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 801
    Points : 34 063
    Points
    34 063
    Billets dans le blog
    14
    Par défaut
    Oui, c'est l'idée que j'avais de modifier ma méthode en créant un script bash qui lance autant de commandes mysql qu'il y a de fichiers de patches à lancer.

    Je vais tester ça parce que je ne vois pas comment faire autrement.

Discussions similaires

  1. Boucle dans un fichier .sql
    Par mouaa dans le forum Outils
    Réponses: 1
    Dernier message: 21/04/2008, 18h05
  2. [ADO] Exécuter des requêtes contenues dans un fichier SQL
    Par Lucas Panny dans le forum Visual C++
    Réponses: 1
    Dernier message: 29/01/2008, 06h35
  3. exporter données d'une table dans un fichier .sql
    Par pierre2410 dans le forum MS SQL Server
    Réponses: 1
    Dernier message: 26/06/2007, 15h29
  4. insérer du csv dans un fichier .sql
    Par sam01 dans le forum SQL Procédural
    Réponses: 5
    Dernier message: 17/01/2007, 13h53
  5. Réponses: 5
    Dernier message: 21/04/2006, 12h03

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo