impossible d'entrer les commandes mysqladmin

Bonjour à tous,

Je précise que je suis un débutant complet en mysql.

Je n'arrive pas à entrer la moindre commande mysqladmin.

Par exemble, voici ce que j'obtiens si je tape:

mysqladmin status -u root -p
->

Une fois que la petite flèche s'est affichée, il ne m'est plus possible de faire quoi que ce soit. Même les commandes mysql ne marchent plus.

Je précise que j'ai bien vérifié que le chemin vers le dossier bin est bien entré. D'autre part, l'exécutable mysqladmin.exe est bien présent dans le dossier bin/.

Merci de votre aide, je suis désespéré.

Je viens de télécharger MySQLadministrator et je l'ai installé. Je n'arrive pas à passer le premier écran de connection.

Je précise que j'ai mis root en password et j'ai mis mon mot de passe sql. Pour le serveur j'ai mis l'adresse ip locale de ma machine (sur laquelle j'ai installé MySQL).

Il m'a renvoyé une erreur 1130. Le ping marche (évidemment).

Bah je suis un sinistre idiot.

Pour utiliser mysqladmin, il faut aller dans l'invite de commande et pas dans la console mysql. Voilà j'ai trouvé...

Bon si vous êtes vraiment gentils maintenant vous allez m'expliquer comment me connecter à mysqladministrator.

Euh... j'ai trouvé aussi.

Désolé.

Mais comment se fait-il que locahost marche et pas l'adresse ip locale de ma machine? Je croyais que c'était pareil

Bonjour,

La raison pour laquelle ça ne marche pas avec l'adresse IP de ta machine, c'est parce que par défaut, le seul utilisateur autorisé à se connecter à MySQL est root, et qu'il ne peut se connecter que depuis l'hôte localhost (et pas depuis une autre adresse IP, quelle qu'elle soit, y compris celle de ta machine).
Ce qui est pareil en terme d'adresse, c'est localhost et l'adresse IP 127.0.0.1.

Tu peux modifier ça dans la gestion des comptes utilisateurs de MySQL : gestion des comptes utilisateurs.

Bon courage ;),

ced

Merci!..

Hihihi, j'ai malgré tout un peu progressé depuis l'époque des messsages ci-dessus. Je continue à développer mon petit serveur web en localhost tranquillement...

A l'heure actuelle il y a simplement un tout petit truc qui m'inquiète un peu concernant MySQL, c'est le problème des caractères spéciaux sous le shell de Windows. Peut-être que quelqu'un pourra m'aider après tout, mais je ne sais pas s'il y a une solution.

Alors voilà, ma base marche parfaitement et j'utilise MySQL Administrator + Query Browser pour toutes mes tâches... sauf pour une, à savoir faire les backups; pour faire mes backups je passe par mysqldump sous la console de Windows "cmd.exe." Il arrive que je me plante dans mes modifs, et alors je dois importer un backup pour restaurer mon travail. Dans ce cas-là il me faut impérativement passer aussi par cmd.exe (à vrai dire j'ai testé des alternatives sans succès).

(en fait, je me suis renseigné, et il paraît que MySQLasministrator est déconseillé pour faire les backups de la bdd au-delà d'une certaine taille; de plus, il me semble que quand j'avais essayé je n'avais même pas réussi à réimporter le backup test que j'avais fait avec).

Le problème c'est qu'avec le shell de windows, tous les caractères spéciaux de ma base ne sont pas correctement retranscrits dans le fichier de sauvegarde .sql. Heureusement, lorsque je fais l'opération inverse de reloader un backup, ils sont tous restaurés. Par contre je n'ai jamais aucun problème avec les accents lorsque j'échange des données entre mes scripts php et ma base de donnée, ou lorsque je fais un copier-coller depuis un traitement de texte vers une case d'une de mes tables, ou nimporte quoi d'autre à vrai dire... en fait tout se passe bien sauf quand je passe par le shell; donc je pense que tout ça est de la "faute" de cmd.exe qui ne gère pas bien le latin1. De même lorsque je fais un INSERT ou un UPDATE en ligne de commande, les accents passent mal, que ce soit dans le Query browser ou bien si je les affiche dans un fichier .php/.html.

Pour être franc je n'y connais rien, mais je ne pense pas que ce soit simplement un problème d'encodage différent entre mon OS (charset inconnu de moi) et MySQL (latin1): si j'ouvre mes fichiers de sauvegarde avec le Query Browser en double-cliquant dessus, les caractères spéciaux s'y affichent de la même manière que dans le shell (c'est à dire mal); par exemple, "é" devient "é"... Par contre, si je restaure ma base en utilisant mysql en ligne de commande, ils retrouvent bien leur état initial.

Bref, tout ça n'est pas trop grave tant que je peux faire des backups et les récupérer, et que les internautes peuvent voir mes pages correctement. La seule chose qui m'inquiète un peu, c'est ce qui va se passer lorsqu'un jour ou l'autre je ferai migrer ma base vers une autre machine, il faudra bien alors que je passe par mysqldump, et que va-t'il arriver? Quelqu'un peut-il me rassurer sur ce point, ou bien faudra-t'il que j'emploie une astuce quelconque pour que ça se passe correctement?

Ce matin j'ai découvert une chose que je trouve véritablement étonnante: il se trouve que j'ai plusieurs procédures stockées dont je compte me servir pour faire fonctionner mon site web, la plus importante d'entre elles étant celle qui me permet de publier les textes que je rédige. J'ai voulu faire un petit script DOS (une ligne) pour pouvoir l'appeler en un double-clic, sans forcément avoir à passer par le query browser. Et là il s'avère qu'en passant par le script DOS, une partie des accents est transformée en signes cabalistiques. Pas tous les accents, seulement une partie. En fait, j'ai l'impression qu'il se passe la chose suivante:

1) Avec DOS, les accents sont retranscrits correctement lorsque ma procédure se contente de copier des données depuis un point de ma base de donnée vers un autre.

2) mais par contre, toujours avec DOS, lorsque la procédure doit écrire "elle-même" des accents, alors ça ne se passe pas bien. Par exemple, à un moment donné ma procédure appelle une petite fonction qui écrit la date française en toute lettre à partir d'une date au format standard -> au lieu d'obtenir Décembre j'obtiens Décembre.

3) en passant par le Query browser plutôt que par le script DOS, tout se déroule parfaitement bien...

Et pourtant, dans un cas comme dans l'autre, il ne s'agit jamais que de faire un simple CALL, et ensuite c'est la procédure qui gère tout. Vraiment ça me dépasse que dans ces conditions il puisse quand même y avoir une différence entre DOS et le Query Browser...

Au fond c'est pas grave, parce que je vais quand même pouvoir appeler ma procédure en un double-clic, il suffira (j'espère) de faire un script DOS qui appellera un script php qui appellera ma procédure stockée. Ca serait quand même un comble que le DOS réussisse à merdouiller au travers de php (soit-dit en passant, j'ai aussi des problèmes avec les interactions entre php et DOS, mais j'arrive plus ou moins à les contourner). En fait c'est juste que je voudrais bien comprendre pour être capable d'anticiper les éventuels problèmes de migration ou autre à long terme.

Citation:

---

Envoyé par Christophe30

Merci!..

A l'heure actuelle il y a simplement un tout petit truc qui m'inquiète un peu concernant MySQL, c'est le problème des caractères spéciaux sous le shell de Windows. Peut-être que quelqu'un pourra m'aider après tout, mais je ne sais pas s'il y a une solution.

---

essaie ça :

Code:

---

SET NAMES cp850 ;

---

Pour l'explication et les détails, voir mon article (cité en signature).

SET NAMES cp850

Ca marche à première vue! Maintenant je vais essayer de faire un backup je te dirai ce qui s'est passé.
___________________________

Avant d'appliquer la commande ci-dessus sous le shell DOS, j'ai fait quelques petits essais entre DOS, php et le Query Browser...

J'ai fait le test suivant:
SELECT _latin1'été', _utf8'été', _cp850'été'

Voici ce que je récupère sous le client DOS:
+-----+-----+-----+
| été | ?t? | ÚtÚ |
+-----+-----+-----+
| été | ?t? | ÚtÚ |
+-----+-----+-----+

Dans le client DOS après avoir fait SET NAMES cp850:

+-----+-----+-----+
| ?t? | ?t? | été |
+-----+-----+-----+
| ?t? | ?t? | été |
+-----+-----+-----+
1 row in set (0.01 sec)

Par contre avec le Query Browser j'obtiens:

'été', 'été', '├®t├®'

Donc il semblerait que le jeu de caractères client de mon Query Browser soit utf8 tandis que celui du shell windows (avant correctif) serait latin1? Pourtant mes bases sont en latin1, et le premier se somporte bien plus correctement que le second tant qu'on n'a pas appliqué le correctif.
____________________________________

Après avoir fait un SET NAMES dans le DOS, le comportement de ce dernier se rapproche de celui de php et du Query Browser.

Les trois semblent se comporter pareil pour tous les types de colonnes sauf BLOB.

Pour les colonnes de type BLOB, elles ne s'affichent correctement dans le query browser ou dans mon navigatuer QUE si je les ai éditées avec un script php, et que j'ai lancé celui-ci depuis mon navigateur. Elles ne s'affichent correctement sous le client DOS QUE si je les ai éditées avec le client DOS. Elles ne s'affichent correctement nulle part si je les ai éditées avec le Query Browser.

Au niveau des blobs, il semble que la correction SET NAMES cp850 n'a aucun impact. D'autre part, c'est le seul type qui ne se comporte pas pareil entre php, DOS après le correctif et Query Browser.

A noter qu'un script php lancé depuis le client DOS pour updater une table se comporte exactement comme une requête lancée sur le client DOS avec l'utilitaire mysql... L'astuce que je voulais appliquer hier n'aurait donc pas marché...

Le cas des colonnes de type TEXT est lui aussi particulier, même si elles s'affichent de la même manière que ce soit sur une fenêtre de navigateur, dans le client DOS "corrigé" ou le Query Browser (affichage des tables après un SELECTou bien Field Viewer onglet "Text"). Après avoir appliqué le SET NAMES cp850 au DOS, on peut utliser nimporte quel moyen pour les éditer, ça ne change rien. Par contre, les caractères spéciaux ne sont pas affichés correctement dans l'onglet "Binary" du Field Viewer du Query Browser.

Maintenant je vais essayer un backup mysqldump après le correctif du DOS...

Je n'ai pas réussi à imposer cp850 à mysqldump... Par contre,

mysqldump --default-character-set=latin1 m'a corrigé la plupart de mes accents dans le fichier .sql!

mysqldump --default-character-set=utf8 n'a rien changé par rapport à ce que j'obtiens d'habitude (normal puisque c'est la valeur par défaut).

mysqldump --default-character-set=cp850 n'a pas fonctionné (message d'erreur, fichier de sortie vide).

En fait je ne suis pas certain que ce soit la bonne option, puisqu'il s'agit ici du character set du client, pas de celui de la base... Mais bon, je vais encore faire une ou deux vérifs et je vais probablement l'adopter.

mysqldump --default-character-set=latin1 --user= etc.

Les seuls accents qui ne sont pas passés avec ça sont ceux de la fameuse procédure stockée qui écrit la date en français en toute lettre à partir de la date au format standard.

Ca s'explique plus ou moins, car les tables de la bdd "mysql" sont en utf8.

De plus, le corps des procédures est mis dans une colonne blob.

Mais bref, de toutes façons il semble que l'utilitaire mysql se débrouille toujours pour restaurer les bases correctement...

Pour en finir avec cette histoire, je suis presque sûr que mon problème d'accent lors de l'appel de ma procédure sous le shell XP était finalement du au fait que le corps des procédures stockées est placé dans une colonne blob...

J'ai créé une table dans laquelle j'ai mis les noms des 12 mois de l'année en français et j'ai modifié ma procédure pour qu'elle utilise cette table au lieu d'écrire les mois elle-même. Ca a résolu mon pb.

Mais merci pour l'astuce SET NAMES cp850, ça va me servir par ailleurs. Je vais pouvoir appeler des requêtes depuis des scripts .bat (l'avantage par rapport au php dans mon utilisation est que c'est plus direct, je peux les appeler en un double-clic).