Traitement de résultats de requêtes SQL - Page 1

Je cherche à savoir si l'on peut traiter des résultats bruts de requêtes après avoir clos la connexion avec la base de données.

L'idée était d'alléger mon code en créant une classe, et je pensais me faire une fonction qui m'ouvrirait la connexion, m'effectuerait la requête donnée et refermerait la connexion de suite après - bien sûr, je récupère le résultat de la requête.
Puis une autre fonction qui m'effectue simplement mysql_fetch_…. Est-ce que ça va fonctionner si la connexion a été fermée entre la requête et son traitement ?

Merci

[Edit] Oups, coquille dans le titre. Si un admin passe par là, serait-il possible de rajouter le r manquant ? Merci

normalement il me semble que ca marche.

sauf que c'est un coup à fermer trop rapidement à connexion si tu veux faire d'autres requêtes ensuite.

par contre, tu peux faire une classe d'interface, avec la connexion dans le constructeur et la déconnexion dans le destructeur

par contre, je te conseille surtout de faire un freeresult, ca peut etre beaucoup plus important que de fermer rapidement la connexion, suivant combien de connexion à la seconde ton appli supporte.

autre point de vue : est ce vraiment utile de fermer la connexion à la db?

C'était juste pour savoir si je pouvais me faire une fonction qui envoie la requête et ferme la connexion de suite après, car j'ai beaucoup de pages qui fonctionnent avec un seul accès nécessaire à la BDD.

Merci à vous deux

Bon, je vais abuser des services des yAronautes pendant un moment encore…

J'ai donc des pages encodées en utf-8. Une base de données encodées en utf8_general_ci. Normalement.
Quand je l'exporte, je sauvegarde le fichier en utf-8 (sans BOM) avec Notepad++. Quand je l'importe sur un autre ordinateur, mon encodage qui fonctionne sur l'un (comprendre par là que mes pages s'y affichent sans problème de jeu de caractères) ne fonctionne plus : c'est comme si j'avais mes valeurs encodées en ISO-8859-1 dans cette base de données fraîchement importée. Je crois en fait que PHP me renvoie mes données encodées ainsi, car quand j'affiche mes données avec phpMyAdmin, elles s'affichent lisiblement, et la page est en utf-8.

J'ai déjà essayé avec utf8_encode, mais ça ne fonctionne pas, car j'ai toujours certains caractères qui ne s'affichent pas correctement.

Le pire, c'est que si je fais une insertion dans la base de données via un formulaire personnel, les données que je récupère ensuite pour affichage sont dans le bon encodage, malgré les é et autres 〦 qui s'affichent lors du parcours de la BDD avec phpMyAdmin…
Si je fais une insertion dans la base via phpMyAdmin, les données ont l'air valables, mais quand je les récupères, ce n'est à nouveau pas le cas…

Est-ce qu'il y a un encodage spécial – tant pour l'interclassement général que pour mon fichier SQL – afin que je n'aie pas à taper ces pseudo-entités utf-8 dans mon fichier SQL, ni que je aie à retoucher les données après l'importation ?

Merci

J'ai déja eu le pb.

ne cherche pas a afficher de l'utf 8 correctement avec phpmyadmin. Le codage de la base et celui de l'affichage sont différents.

d'ailleurs le codage de la db est totalement inutile, code le en ce que tu veux, et php y stockera ce qu'il veut même si ça correspond pas a ce que t'as choisi.

il te faut faire confiance a *ton* programme php qui va pêcher et stocker dans ta base sql, pas à ce qu'affiche phpmyadmin.

squalyl (./6) :
d'ailleurs le codage de la db est totalement inutile, code le en ce que tu veux, et php y stockera ce qu'il veut même si ça correspond pas a ce que t'as choisi.

Oui et non, c'est une solution très crade de contourner le problème. Bien sûr que si tu sauvegardes des données dans tes tables, au moment de la restitution MySQL te les donnera exactement telles que tu les as enregistrées, mais ça ne veut pas dire que c'est sans conséquence.

Il faut savoir que MySQL prend en compte l'encodage que tu as spécifié pour tes tables, par exemple pour savoir comment classer les textes quand tu lui demandes de les restituer par ordre alphabétique (pour reconnaitre un "à" et savoir comment le comparer à un "b", il faut déjà savoir comment il se code). Enfin plus exactement c'est l'interclassement qui détermine ça, mais ça va ensemble.

Quand tu communiques avec MySQL depuis ton code PHP, MySQL s'attend à recevoir des données dans un encodage bien précis (on va l'appeler "A"), et si ça n'est pas le même que celui de la table dans laquelle les données doivent être stockées (notons-le "B"), il va effectuer une conversion d'encodage A->B. Dans le sens inverse, quand tu récupères tes données, il effectue une conversion B->A et tu retrouves exactement ce que tu avais sauvegardé.

Tout ça ne marche donc que si tu connais "A" : si tu commences par injecter des données en UTF-8 dans les tables depuis X programmes différents alors que certains ne spécifient pas que "A" est de l'UTF-8 (j'imagine que phpMyAdmin fait les choses correctement, mais peut-être pas ton code), tu as toutes les chances de te retrouver avec de la bouillie dans tes tables. Si ton site est en UTF-8 et que tes tables également, il faut soit que tu changes la configuration de MySQL pour que l'encodage "A" soit par défaut de l'UTF-8, soit le déclarer dans ton programme juste après avoir effectué la connexion, avec la commande "SET NAMES 'UTF-8'".

Plus d'infos ici : http://dev.mysql.com/doc/refman/5.0/fr/charset-connection.html

t'as fait un gros pavé pour "rien" (on s'entend) parce que je le sais

sauf que j'ai jamais vu la conversion marcher ^^

squalyl (./8) :
t'as fait un gros pavé pour "rien" (on s'entend) parce que je le sais

tu n'en donnais pas l'impression.

sauf que j'ai jamais vu la conversion marcher ^^

elle fonctionne parfaitement si on s'en sert correctement.

SET NAMES 'utf8'

Ça résout mes problèmes, merci ! (C'est juste les premiers résultats sous Google, mais bon… )

ah tiens y'a pas de tiret entre UTF et 8, désolé ^^

Boah, c'est pas la mort.

Je signale quand-même que cette solution est dépréciée en faveur de mysql_set_charset qui a été introduite dans PHP 5.2.3 et MySQL 5.0.7. (Il faut ces versions minimum des deux pour l'utiliser.)

Merci Kevin, seulement je pense qu'il y a plus de serveurs qui utilisent des version "moins avancées" de PHP et MySQL. Mais je note.

Kevin Kofler (./13) :
Je signale quand-même que cette solution est dépréciée en faveur de mysql_set_charset qui a été introduite dans PHP 5.2.3 et MySQL 5.0.7. (Il faut ces versions minimum des deux pour l'utiliser.)

à noter que ca marchait déjà avec la version 5.1.6 de PHP

Pourtant, la doc dit 5.2.3…

Et les 10 commandements disent « Tu ne tueras point. »… malgré ça… ^^

T'as juré de te payer Kevin, Golden ?