J'ai activé l'accès SQL à un de mes comptes supplémentaires hier soir,
mais l'accès continue de planter avec "Could not connect: Unknown
MySQL Server Host 'monlogin.sql.free.fr' (2)"
Quelqu'un sait si ça demande juste quelques heures de plus, ou si,
suite au grand changement de juillet, les accès SQL sont également
réservés aux clients Free?
Pour info, l'accès SQL marche tj avec le compte principal.
"laurent.D" a écrit dans le message de news: 41b21497$0$2307$
Bonjour,
Je croyais que ce n'était pas nécessaire et que la connexion se fermait toutes seule à la fin du script. Quel probleme cela génère au niveau de la base ?
Apres vérif dans la doc, la connexion se referme toute seule apres exec, donc mea culpa, c'est une vieille habitude de libérer les ressources :o)
Doit on ou ne doit on pas utiliser mysql_close pour coder proprement ?
On peut, si on veut, mais pas obligé
@+ Rémy
"laurent.D" <laurent.dt@no.mail> a écrit dans le message de news:
41b21497$0$2307$636a15ce@news.free.fr...
Bonjour,
Je croyais que ce n'était pas nécessaire et que la connexion se fermait
toutes seule à la fin du script. Quel probleme cela génère au niveau de
la base ?
Apres vérif dans la doc, la connexion se referme toute seule apres exec,
donc mea culpa, c'est une vieille habitude de libérer les ressources :o)
Doit on ou ne doit on pas utiliser mysql_close pour coder proprement ?
"laurent.D" a écrit dans le message de news: 41b21497$0$2307$
Bonjour,
Je croyais que ce n'était pas nécessaire et que la connexion se fermait toutes seule à la fin du script. Quel probleme cela génère au niveau de la base ?
Apres vérif dans la doc, la connexion se referme toute seule apres exec, donc mea culpa, c'est une vieille habitude de libérer les ressources :o)
Doit on ou ne doit on pas utiliser mysql_close pour coder proprement ?
On peut, si on veut, mais pas obligé
@+ Rémy
Patrick Mevzek
Et il est ou le mysql_close() ??
C'est pas bien de laisser une connexion en plan comme ca :o))
Je croyais que ce n'était pas nécessaire et que la connexion se fermait
toutes seule à la fin du script. Quel probleme cela génère au niveau de la base ?
Garder des connexions ouvertes pour rien. Entre le moment où votre programme cesse d'avoir besoin de la connexion, et le moment où le programme se termine ce qui effectivement devrait forcer l'interpréteur à clore les connexions (mais pas forcément immédiatement, et ce n'est pas forcément le cas pour tous les SGBDR), votre programme peut continuer à faire plein de choses, et il monopolise alors une connexion à la base pour rien.
Les SGBDR limitent le nombre de connexions simultanées, donc...
Et par contre coup certains hébergeurs mettent une limite par compte (genre 2 ou 5). Et là ca vous impacte, parce que pendant tout le temps où la connexion est monopolisée sans être utilisée, ca compte dans votre ``quota'', et peut empêcher donc une autre instance (ie un autre visiteur) de votre application de s'exécuter correctement.
Doit on ou ne doit on pas utiliser mysql_close pour coder proprement ?
On doit. On nettoie/ferme/détruit/etc... derrière soi dès qu'on n'a plus besoin d'un élément.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Et il est ou le mysql_close() ??
C'est pas bien de laisser une connexion en plan comme ca :o))
Je croyais que ce n'était pas nécessaire et que la connexion se fermait
toutes seule à la fin du script. Quel probleme cela génère au niveau de
la base ?
Garder des connexions ouvertes pour rien.
Entre le moment où votre programme cesse d'avoir besoin de la connexion,
et le moment où le programme se termine ce qui effectivement devrait
forcer l'interpréteur à clore les connexions (mais pas forcément
immédiatement, et ce n'est pas forcément le cas pour tous les SGBDR),
votre programme peut continuer à faire plein de choses, et il monopolise
alors une connexion à la base pour rien.
Les SGBDR limitent le nombre de connexions simultanées, donc...
Et par contre coup certains hébergeurs mettent une limite par compte
(genre 2 ou 5). Et là ca vous impacte, parce que pendant tout le temps où
la connexion est monopolisée sans être utilisée, ca compte dans votre
``quota'', et peut empêcher donc une autre instance (ie un autre
visiteur) de votre application de s'exécuter correctement.
Doit on ou ne doit on pas utiliser mysql_close pour coder proprement ?
On doit.
On nettoie/ferme/détruit/etc... derrière soi dès qu'on n'a plus besoin
d'un élément.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
C'est pas bien de laisser une connexion en plan comme ca :o))
Je croyais que ce n'était pas nécessaire et que la connexion se fermait
toutes seule à la fin du script. Quel probleme cela génère au niveau de la base ?
Garder des connexions ouvertes pour rien. Entre le moment où votre programme cesse d'avoir besoin de la connexion, et le moment où le programme se termine ce qui effectivement devrait forcer l'interpréteur à clore les connexions (mais pas forcément immédiatement, et ce n'est pas forcément le cas pour tous les SGBDR), votre programme peut continuer à faire plein de choses, et il monopolise alors une connexion à la base pour rien.
Les SGBDR limitent le nombre de connexions simultanées, donc...
Et par contre coup certains hébergeurs mettent une limite par compte (genre 2 ou 5). Et là ca vous impacte, parce que pendant tout le temps où la connexion est monopolisée sans être utilisée, ca compte dans votre ``quota'', et peut empêcher donc une autre instance (ie un autre visiteur) de votre application de s'exécuter correctement.
Doit on ou ne doit on pas utiliser mysql_close pour coder proprement ?
On doit. On nettoie/ferme/détruit/etc... derrière soi dès qu'on n'a plus besoin d'un élément.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
laurent.D
Doit on ou ne doit on pas utiliser mysql_close pour coder proprement ?
On peut, si on veut, mais pas obligé
Merci Remy, mais je vois que tout le monde n'est pas d'accord sur le sujet... Cordialement
Doit on ou ne doit on pas utiliser mysql_close pour coder proprement ?
On peut, si on veut, mais pas obligé
Merci Remy, mais je vois que tout le monde n'est pas d'accord sur le
sujet...
Cordialement
Doit on ou ne doit on pas utiliser mysql_close pour coder proprement ?
On peut, si on veut, mais pas obligé
Merci Remy, mais je vois que tout le monde n'est pas d'accord sur le sujet... Cordialement
laurent.D
Garder des connexions ouvertes pour rien. Entre le moment où votre programme cesse d'avoir besoin de la connexion, et le moment où le programme se termine ce qui effectivement devrait forcer l'interpréteur à clore les connexions (mais pas forcément immédiatement, et ce n'est pas forcément le cas pour tous les SGBDR), votre programme peut continuer à faire plein de choses, et il monopolise alors une connexion à la base pour rien.
Idem avec MySql ?
Les SGBDR limitent le nombre de connexions simultanées, donc...
Et par contre coup certains hébergeurs mettent une limite par compte (genre 2 ou 5). Et là ca vous impacte, parce que pendant tout le temps où la connexion est monopolisée sans être utilisée, ca compte dans votre ``quota'', et peut empêcher donc une autre instance (ie un autre visiteur) de votre application de s'exécuter correctement.
Doit on ou ne doit on pas utiliser mysql_close pour coder proprement ?
On doit. On nettoie/ferme/détruit/etc... derrière soi dès qu'on n'a plus besoin d'un élément.
Merci Patrick, c'est vrais que ca ne coute rien de prendre ces habitudes.
Garder des connexions ouvertes pour rien.
Entre le moment où votre programme cesse d'avoir besoin de la connexion,
et le moment où le programme se termine ce qui effectivement devrait
forcer l'interpréteur à clore les connexions (mais pas forcément
immédiatement, et ce n'est pas forcément le cas pour tous les SGBDR),
votre programme peut continuer à faire plein de choses, et il monopolise
alors une connexion à la base pour rien.
Idem avec MySql ?
Les SGBDR limitent le nombre de connexions simultanées, donc...
Et par contre coup certains hébergeurs mettent une limite par compte
(genre 2 ou 5). Et là ca vous impacte, parce que pendant tout le temps où
la connexion est monopolisée sans être utilisée, ca compte dans votre
``quota'', et peut empêcher donc une autre instance (ie un autre
visiteur) de votre application de s'exécuter correctement.
Doit on ou ne doit on pas utiliser mysql_close pour coder proprement ?
On doit.
On nettoie/ferme/détruit/etc... derrière soi dès qu'on n'a plus besoin
d'un élément.
Merci Patrick, c'est vrais que ca ne coute rien de prendre ces habitudes.
Garder des connexions ouvertes pour rien. Entre le moment où votre programme cesse d'avoir besoin de la connexion, et le moment où le programme se termine ce qui effectivement devrait forcer l'interpréteur à clore les connexions (mais pas forcément immédiatement, et ce n'est pas forcément le cas pour tous les SGBDR), votre programme peut continuer à faire plein de choses, et il monopolise alors une connexion à la base pour rien.
Idem avec MySql ?
Les SGBDR limitent le nombre de connexions simultanées, donc...
Et par contre coup certains hébergeurs mettent une limite par compte (genre 2 ou 5). Et là ca vous impacte, parce que pendant tout le temps où la connexion est monopolisée sans être utilisée, ca compte dans votre ``quota'', et peut empêcher donc une autre instance (ie un autre visiteur) de votre application de s'exécuter correctement.
Doit on ou ne doit on pas utiliser mysql_close pour coder proprement ?
On doit. On nettoie/ferme/détruit/etc... derrière soi dès qu'on n'a plus besoin d'un élément.
Merci Patrick, c'est vrais que ca ne coute rien de prendre ces habitudes.
Stephane Kanschine
Le Sat, 04 Dec 2004 14:46:06 +0100, Mat Free a écrit :
La connexion est automatiquement fermée à la fin de l'execution du script.
Et si un jour le site se retrouve sur un hébergement en module ? C'est pas parce que la configuration te facilité la vie qu'il ne faut pas essayer de faire propre.
-- Stephane Kanschine Amadouer l'anti-spam pour me répondre
Le Sat, 04 Dec 2004 14:46:06 +0100, Mat Free a écrit :
La connexion est automatiquement fermée à la fin de l'execution
du script.
Et si un jour le site se retrouve sur un hébergement en module ?
C'est pas parce que la configuration te facilité la vie qu'il ne
faut pas essayer de faire propre.
--
Stephane Kanschine
Amadouer l'anti-spam pour me répondre
Le Sat, 04 Dec 2004 14:46:06 +0100, Mat Free a écrit :
La connexion est automatiquement fermée à la fin de l'execution du script.
Et si un jour le site se retrouve sur un hébergement en module ? C'est pas parce que la configuration te facilité la vie qu'il ne faut pas essayer de faire propre.
-- Stephane Kanschine Amadouer l'anti-spam pour me répondre
Mat Free
La connexion est automatiquement fermée à la fin de l'execution du script.
Et si un jour le site se retrouve sur un hébergement en module ? C'est pas parce que la configuration te facilité la vie qu'il ne faut pas essayer de faire propre.
Si j'ai bien compris, la connexion est fermée dans tous les cas. Enfin la doc ne précise rien.
-- Mat
La connexion est automatiquement fermée à la fin de l'execution
du script.
Et si un jour le site se retrouve sur un hébergement en module ?
C'est pas parce que la configuration te facilité la vie qu'il ne
faut pas essayer de faire propre.
Si j'ai bien compris, la connexion est fermée dans tous les cas.
Enfin la doc ne précise rien.
La connexion est automatiquement fermée à la fin de l'execution du script.
Et si un jour le site se retrouve sur un hébergement en module ? C'est pas parce que la configuration te facilité la vie qu'il ne faut pas essayer de faire propre.
Si j'ai bien compris, la connexion est fermée dans tous les cas. Enfin la doc ne précise rien.
