Script SQL et PHP

Bonjour, je voudrais appeler un script .sql à base de requête d'insertion depuis une page .php. Je voudrais savoir s'il est possible de dire si l’exécution du script entier est OK dans un fichier .log ?... Ou bien je devrai taper les requêtes une par une et écrire le déroulement dans un fichier.log au fur et à mesure ?
Merci;

Salut

Je ne vois pas vraiment à quoi ça avancerait de savoir que tel ou tel script (ou requête) c'est bien déroulé.

Dans la majorité des cas on fait plutôt l'inverse, c'est à dire qu'on n'y met essentiellement des messages d'erreurs dans des fichiers de log afin de les consulter pour les réparer ensuite.
Là c'est vraiment utile, voire essentiel.


Donc à mon sens il serait mieux de rajouter toutes sortes de vérifications, quitte à déclencher des erreurs volontairement qui après coup seront enregistrés dans le log d'erreur de Php.
Cela s'appel de la gestion des erreurs.
-> try/catch, thow new Exception, trigger_error, etc ...


Ou alors du coté de MySQL, si cela concerne essentiellement de requêtes SQL, les transactions (COMMIT/ROLLBACK).

Oui c'est du MySQL, j'envoie des données d'une BDD vers une autre depuis le script .sql, je suis obligé de lancer les requêtes une par une pour voir si les requêtes passent ou non ? (si non je renseigne un fichier log)
L'idéal serait dans un 1er temps de lancer le script .sql et de voir si l'execution renvoie une erreur ou non (en batch c'est possible ...) ?

Citation:

---

je suis obligé de lancer les requêtes une par une pour voir si les requêtes passent ou non ? (si non je renseigne un fichier log)

---

Tu peux faire ce que tu veux.

Mais on ne sait pas de quoi il s'agit, du coup on ne peu pas te répondre avec certitude.

Si par exemple il y a 2 requêtes d'insertions, et que les 2 tables sont liées entre elles (clé primaire, clé secondaire), dans tel cas il est préférable que les 2 se fasses sans aucune erreur.
Cela sous-entend que si une erreur venait à arrivée, il vaudrait mieux annuler cet ensemble de requêtes pour se retrouver exactement dans la même situation que si rien avait été fait.

Si on ne fait pas ça, la Bdd sera corrompue, et c'est bug garanti lorsqu'on exploitera ces données là.

Dans tel cas il est bon d'exploiter les transactions (commit/rollback).


Vois tu, ce n'est pas aussi simple vu qu'on ne sait pas de quoi il s'agit.

Au fait c'est un outil pour centraliser des BDD.
Oui ca serait pas mal de pouvoir gérer le fait que si une table n'est pas entré on supprime les entrées précédentes ... Avez vous une piste pour commencer cela ?
Merci!

J'ai pensé à utiliser ce bout de code pour gérer les erreurs, si une erreur intervient toutes les données entrés précédemment ne seront pas sauvegardés dans la BDD ? Si par exemple l'erreur intervient à l'écriture dans la 10 éme table ça sa passe comment ?
Je voudrai aussi qu'en cas d'erreur je quitte le programme et j'entre un message dans un fichier .log.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

if(!$result) { rollback(); // transaction rolls back echo "transaction rolled back"; exit; } else { commit(); // transaction is committed echo "Database transaction was successful"; }

---

ps: j'ai crée des fonctions rollback et commit ...
Je voudrai aussi de l'aide quant à l'écriture de la requête suivante (je me connecte à une BDD avant ...) :

Code:

---

1 2 3

$insertion = "INSERT INTO table (champs_id,champs_2, champs_3, champs_4,champs_5,champs_6) SELECT bdd2.champs_id, bdd2.champs_2, bdd2.champs_3, bdd.champs_4, bdd2.champs_5, '$reference' FROM bdd2.table"

---

MERCI !

Bonjour,
je pense que l'erreur vient du $reference, qui semble être une variable?
SELECT doit être suivi d'une liste de noms de colonnes.

Allegro, la requete est ici un insert, on peut supposer que sa variable php contient le nom d'une colonne de sa base, est ce bien le cas SNY77?

Je ne suis pas sur que tu puisse faire des requètes comme ceci directement entre deux base de données différentes, ou alors essaye INSERT INTO bdd1.table

Concernant la gestion des erreurs pour l'éxecution des requêtes d'insertion, c'est bon ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11

if(!$result) { rollback(); // transaction rolls back echo "transaction rolled back"; exit; } else { commit(); // transaction is committed echo "Database transaction was successful"; }

---

Parcontre aprés un commit c'est toute la transaction qui se ferme ? Donc ca ne supprime pas tous les derniers enregistrements ?
Merci;

Citation:

---

Parcontre aprés un commit c'est toute la transaction qui se ferme ? Donc ca ne supprime pas tous les derniers enregistrements ?
Merci;

---

Oui.
Du moins je ne dirais pas "fermer" mais plutôt "valider"
On spécifie au SGBDR de valider le paquet (ou l'ensemble) que compose la transaction.

Mais pas d'amalgame. COMMIT est une instruction du langage SQL, pas de Php.
Même si PDO (pour exemple) permet d'exécuter en Php une commit/rollback, PDO reste néanmoins une abstraction, ça revient pas loin d'exécuter un code SQL.
Ce que je veux dire par là, c'est qu'un commit ou rollback ne pourra pas avoir d'action sur un code Php.
Si pendant l'exécution de l'ensemble des requêtes SQL que compose une transaction un code Php "plante", même pour une simple erreur, le script Php se poursuivra, du moins s'il n'est pas stoppé volontairement ou pas (genre erreur fatale).

C'est tout de même en parti faux, car si le script est arrêté (erreur fatale en Php ou autre façon), et que toutes les requêtes SQL de la transaction ne sont pas terminées/exécutées, ce qui revient à ne pas exécuter de commit ou rollback, théoriquement le SGBDR devrait le considérer comme un rollback (annulation de la transaction).


Faut en toute évidence que tu utilise une BDD transactionnelle (et obligatoirement Relationnelle aussi si je ne dis pas de bêtise).

Le moteur InnoBD de MySQL par exemple (le moteur MyISAM est ni Relationnel et ni transactionnel, soit dit en passant).

Je dois m'y prendre comment alors ? Si ce n'est pas possible de tout supprimer en cas d'erreurs, je peux très bien faire un back up avant et le reimporter en cas d'erreur . Mais la solution de vérification requête par requête me parait meilleure, mon bout de code est correct ? Si oui je l'appliquerai pour toutes mes requêtes.
Merci;

Citation:

---

Si ce n'est pas possible de tout supprimer en cas d'erreurs

---

Je dois mal m'exprimer, ou je ne sais pas quoi d'autre. :roll:

A aucun moment une instruction SQL comme ROLLBACK supprime des enregistrements liés à une erreur.
Attention pas de mauvaise compréhension ou interprétation.
Un ROLLBACK annule l'ensemble d'une transaction et c'est justement cela qui assurera l'intégrité de la BDD dans ce cas de figure, ce qui revient à ne rien faire, à ne rien enregistrer.
Donc si cela n'enregistre rien, il n'y a pas lieu de supprimer.
C'est l'énorme avantage qu'offre un SGBDR transactionnel.


Procéder autrement peut être extrêmement compliqué car il faudra émuler (donc coder manuellement) la même chose, tout dépendra des requêtes exécutées.


Si, en disant cela tu sous-entend que le moteur de MySQL que tu utilises n'est pas transactionnel, effectivement cela est plutôt embêtant.
Par ailleurs, il ne faut oublier que le choix d'un SGBD(R) repose sur son besoin.
Si on fait un mauvais choix on y pourra pas faire grand chose.


Par ailleurs, il est fortement recommandé de faire un backup avant toutes opération sensible, particulièrement dans ton cas, quelque soit le SGBD(R), transactionnel ou pas.
Faire des backup c'est une toute autre problématique.

Citation:

---

Mais la solution de vérification requête par requête me parait meilleure, mon bout de code est correct ?

---

Alors tu ne verras pas vraiment le gros avantage qu'offre de faire une transaction.
De même que tu ne saurais pas vraiment ce que c'est une gestion des erreurs.

Exemple basique : (avec PDO)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

<?php try { $db->beginTransaction(); $result_1 = $db->exec('requete sql -> 1'); ... etc ... $result_2 = $db->exec('requete sql -> n); // Exemple d'erreur dans un traitement Php // $existe_pas n'existerait pas (non initialisé par exemple) $truc = $existe_pas;   $db->commit(); } catch (PDOException $e) { $db->rollback(); echo $e->getMessage(); } catch (Exception $e) { $db->rollback(); echo $e->getMessage(); } ?>

---

Ici, qu'il y ait une erreur dans l'exécution d'une requête, où dû à l'erreur sur $existe_pas, cela sera attrapé (ou catché) par la gestion des erreur, et du coup, quelque soit le cas les requêtes SQL 1 à n seront annulées.
Sans compter qu'on peu aussi lancer ses propres erreurs d'Exception pour certaines vérifications qu'on estimera nécessaire.

Ce à mon sens est largement mieux que de faire autrement, mais c'est à toi de voir.


Maintenant, si tu ne maitrise pas tout cela, il est claire que ça va être difficile de le faire de suite, même rapidement.
Dans ce cas là il faut faire une version V_1 simple, un peu du genre "ça passe ou ça casse" pour plus tard intégrer quelque chose de plus fiable.


A coté de ça, tu évoquais des fichiers SQL (.sql).
Pourquoi ne pas t'orienter à faire un import de ces fichiers directement (un dump) ?

Merci ...
J'ai testé ton bout de code, j'ai modifié le noms d'un champs d'une table pour voir s'il allait m'afficher un message d'erreur, apparemment il n'entre pas dans le catch.

Citation:

---

apparemment il n'entre pas dans le catch

---

Tout est dans la configuration de la gestion des erreurs ou/et des Exception.

Du coté de PDO il faut rajouter un code spécifique pour ça pour (ERRORMODE), sinon par défaut c'est en mode "silence", donc forcément ...
Voir -> PDOException
Si ce n'est pas PDO, faudrait voir quelle est la librairie de Php que tu utilises (MySQL, MySQLi, etc ...).

Et voir aussi du coté du niveau des erreurs de Php (php.ini) pour le mettre au max (error_reporting).
Genre : E_ALL | E_STRICT ou -1


L'idéal serait d'avoir une vrai gestion des erreurs/Exceptions personnalisée, mais comme déjà tu ne vois pas le pourquoi de ton problème à l'instant, ce serait un peu prématuré (ce n'est pas si simple que ça à faire).
Faudrait rajouter ça à l'avenir, on y gagne énormément coté débuggage, et c'est par la suite son application qui y gagnera en fiabilité.

Je voudrais qu'a la fin du script la fenêtre se ferme toute seule (aprés l’exécution) mais ca ne marche pas (j'ai essayé le javascript avec la fonction close mais je dois confirmer en appuyant sur OUI) or je veux que ca se fasse tout seul;
Merci!

Au fait je lance ma page depuis un batch (avec une commande internet explorer ..), je voudrais qu'a la fin de l'exécution du script la page se ferme;