Discussion :

[Christophe30]

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é.

[Christophe30]

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).

[Christophe30]

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.

[Christophe30]

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

[ced]

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

[Christophe30]

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.