Bonjour,
Parmi vous, un bon nombre utilise une base tierce telle que MySQL.
Comment g=E9rez vous les pertes de connexion apr=E8s une longue dur=E9e=20
d'inactivit=E9 ?
Parmi vous, un bon nombre utilise une base tierce telle que MySQL. Comment gérez vous les pertes de connexion après une longue durée d'inactivité ?
Peu importe le SGBD, dans tout traitement : tu ouvres la connexion, tu requêtes et tu fermes.
Roumegou Eric
Gégé a émis l'idée suivante :
Manu Pavy a écrit :
Parmi vous, un bon nombre utilise une base tierce telle que MySQL. Comment gérez vous les pertes de connexion après une longue durée d'inactivité ?
Peu importe le SGBD, dans tout traitement : tu ouvres la connexion, tu requêtes et tu fermes.
Ah bon ? Justement ça se discute ça ! En C/S, cela n'est pas franchement la technique de prédilection.
Par contre, dans un contexte web, j'hésite en ce moment à mettre au point cette technique car j'ai beaucoup de process en sleeping. Pour l'instant, je me connecte au sgbd et je déconnecte à la fermeture de session. Mais je crains que la connexion à chaque requete soit trop impactante sur les temps de réponses.
Des expériences là dessus ?
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Gégé a émis l'idée suivante :
Manu Pavy a écrit :
Parmi vous, un bon nombre utilise une base tierce telle que MySQL.
Comment gérez vous les pertes de connexion après une longue durée
d'inactivité ?
Peu importe le SGBD, dans tout traitement : tu ouvres la connexion, tu
requêtes et tu fermes.
Ah bon ?
Justement ça se discute ça !
En C/S, cela n'est pas franchement la technique de prédilection.
Par contre, dans un contexte web, j'hésite en ce moment à mettre au
point cette technique car j'ai beaucoup de process en sleeping.
Pour l'instant, je me connecte au sgbd et je déconnecte à la fermeture
de session. Mais je crains que la connexion à chaque requete soit trop
impactante sur les temps de réponses.
Des expériences là dessus ?
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Parmi vous, un bon nombre utilise une base tierce telle que MySQL. Comment gérez vous les pertes de connexion après une longue durée d'inactivité ?
Peu importe le SGBD, dans tout traitement : tu ouvres la connexion, tu requêtes et tu fermes.
Ah bon ? Justement ça se discute ça ! En C/S, cela n'est pas franchement la technique de prédilection.
Par contre, dans un contexte web, j'hésite en ce moment à mettre au point cette technique car j'ai beaucoup de process en sleeping. Pour l'instant, je me connecte au sgbd et je déconnecte à la fermeture de session. Mais je crains que la connexion à chaque requete soit trop impactante sur les temps de réponses.
Des expériences là dessus ?
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Manu Pavy
> Ah bon ? Justement ça se discute ça ! En C/S, cela n'est pas franchement la technique de prédilection.
Par contre, dans un contexte web, j'hésite en ce moment à mettre au point cette technique car j'ai beaucoup de process en sleeping.
En web, je connecte généralement dans un script placé en en-tete et déconnecte en fin de traitement de la page car chaque interaction se fait au chargement d'une page. tandis qu une appli doit avoir l avantage d etre relativement "en temps réel".
Pour l'instant, je me connecte au sgbd et je déconnecte à la fermet ure de session. Mais je crains que la connexion à chaque requete soit tro p impactante sur les temps de réponses.
Tel était le sous entendu de ma question : si chaque requete demande un e connexion/déconnexion, cela risque de charger un peu le serveur. Par contre, MySQL déconnecte automatiquement au bout d'un certain temps , comment récupérer cette info ? Et de même, ne serait ce pas trop lo urd de faire un test pour chaque requete. Bref, ce qui est compliqué, c'est que j aimerais que ce soit le serveur qui envoie une info et non le client qui demande.
Des expériences là dessus ?
>
Ah bon ?
Justement ça se discute ça !
En C/S, cela n'est pas franchement la technique de prédilection.
Par contre, dans un contexte web, j'hésite en ce moment à mettre au
point cette technique car j'ai beaucoup de process en sleeping.
En web, je connecte généralement dans un script placé en en-tete et
déconnecte en fin de traitement de la page car chaque interaction se
fait au chargement d'une page. tandis qu une appli doit avoir l avantage
d etre relativement "en temps réel".
Pour l'instant, je me connecte au sgbd et je déconnecte à la fermet ure
de session. Mais je crains que la connexion à chaque requete soit tro p
impactante sur les temps de réponses.
Tel était le sous entendu de ma question : si chaque requete demande un e
connexion/déconnexion, cela risque de charger un peu le serveur.
Par contre, MySQL déconnecte automatiquement au bout d'un certain temps ,
comment récupérer cette info ? Et de même, ne serait ce pas trop lo urd
de faire un test pour chaque requete. Bref, ce qui est compliqué, c'est
que j aimerais que ce soit le serveur qui envoie une info et non le
client qui demande.
> Ah bon ? Justement ça se discute ça ! En C/S, cela n'est pas franchement la technique de prédilection.
Par contre, dans un contexte web, j'hésite en ce moment à mettre au point cette technique car j'ai beaucoup de process en sleeping.
En web, je connecte généralement dans un script placé en en-tete et déconnecte en fin de traitement de la page car chaque interaction se fait au chargement d'une page. tandis qu une appli doit avoir l avantage d etre relativement "en temps réel".
Pour l'instant, je me connecte au sgbd et je déconnecte à la fermet ure de session. Mais je crains que la connexion à chaque requete soit tro p impactante sur les temps de réponses.
Tel était le sous entendu de ma question : si chaque requete demande un e connexion/déconnexion, cela risque de charger un peu le serveur. Par contre, MySQL déconnecte automatiquement au bout d'un certain temps , comment récupérer cette info ? Et de même, ne serait ce pas trop lo urd de faire un test pour chaque requete. Bref, ce qui est compliqué, c'est que j aimerais que ce soit le serveur qui envoie une info et non le client qui demande.
Des expériences là dessus ?
Gégé
Roumegou Eric a écrit :
Justement ça se discute ça ! En C/S, cela n'est pas franchement la technique de prédilection.
Bin si ! Et comme cela, tu t'évites bien des problèmes d'index. Parce que ouvrir la connexion au lancement de l'appli et la laisser ouverte, c'est pas terrible.
Roumegou Eric a écrit :
Justement ça se discute ça !
En C/S, cela n'est pas franchement la technique de prédilection.
Bin si ! Et comme cela, tu t'évites bien des problèmes d'index. Parce
que ouvrir la connexion au lancement de l'appli et la laisser ouverte,
c'est pas terrible.
Justement ça se discute ça ! En C/S, cela n'est pas franchement la technique de prédilection.
Bin si ! Et comme cela, tu t'évites bien des problèmes d'index. Parce que ouvrir la connexion au lancement de l'appli et la laisser ouverte, c'est pas terrible.
Roumegou Eric
Gégé a pensé très fort :
Roumegou Eric a écrit :
Justement ça se discute ça ! En C/S, cela n'est pas franchement la technique de prédilection.
Bin si ! Et comme cela, tu t'évites bien des problèmes d'index.
Pour m'éviter les problèmes d'index, je travaille avec des SGBD comme Oracle ou mySQL. C'est quoi les problèmes d'index ?? Moi les seuls problèmes d'index que je connaisse, c'est la coupure que je me suis faite au doigt en bricolant hier soir (véridique ;-) )
Parce que ouvrir la connexion au lancement de l'appli et la laisser ouverte, c'est pas terrible.
Je travaille comme cela depuis très longtemps et je n'ais pas rencontré de pb. Il faut dire que je n'ai jamais eu plus de 50 connectés en meme temps sur une appli. Par contre sur mon site, je suis monté à plus de 100 cnx simultanées. La solution serait peut être un timer qui au bout d'un certain temps d'inactivités, enverrait un sqldeconnecte.
Le plus sexy serait un pool de connexions sur la base et l'on ferait appel à ce pool qui récupérerait une connexion dispo. On utilisait ce principe en java pour accéder à une base Oracle (ds une autre vie)
Manu, si tu me lit, ça titillerait pas tes neurones ça pour rajouter ce type d'accès aux accès alternatifs ????
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Gégé a pensé très fort :
Roumegou Eric a écrit :
Justement ça se discute ça !
En C/S, cela n'est pas franchement la technique de prédilection.
Bin si ! Et comme cela, tu t'évites bien des problèmes d'index.
Pour m'éviter les problèmes d'index, je travaille avec des SGBD comme
Oracle ou mySQL. C'est quoi les problèmes d'index ??
Moi les seuls problèmes d'index que je connaisse, c'est la coupure que
je me suis faite au doigt en bricolant hier soir (véridique ;-) )
Parce que ouvrir la connexion au lancement de l'appli et la laisser ouverte,
c'est pas terrible.
Je travaille comme cela depuis très longtemps et je n'ais pas rencontré
de pb. Il faut dire que je n'ai jamais eu plus de 50 connectés en meme
temps sur une appli.
Par contre sur mon site, je suis monté à plus de 100 cnx simultanées.
La solution serait peut être un timer qui au bout d'un certain temps
d'inactivités, enverrait un sqldeconnecte.
Le plus sexy serait un pool de connexions sur la base et l'on ferait
appel à ce pool qui récupérerait une connexion dispo.
On utilisait ce principe en java pour accéder à une base Oracle (ds une
autre vie)
Manu, si tu me lit, ça titillerait pas tes neurones ça pour rajouter ce
type d'accès aux accès alternatifs ????
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Justement ça se discute ça ! En C/S, cela n'est pas franchement la technique de prédilection.
Bin si ! Et comme cela, tu t'évites bien des problèmes d'index.
Pour m'éviter les problèmes d'index, je travaille avec des SGBD comme Oracle ou mySQL. C'est quoi les problèmes d'index ?? Moi les seuls problèmes d'index que je connaisse, c'est la coupure que je me suis faite au doigt en bricolant hier soir (véridique ;-) )
Parce que ouvrir la connexion au lancement de l'appli et la laisser ouverte, c'est pas terrible.
Je travaille comme cela depuis très longtemps et je n'ais pas rencontré de pb. Il faut dire que je n'ai jamais eu plus de 50 connectés en meme temps sur une appli. Par contre sur mon site, je suis monté à plus de 100 cnx simultanées. La solution serait peut être un timer qui au bout d'un certain temps d'inactivités, enverrait un sqldeconnecte.
Le plus sexy serait un pool de connexions sur la base et l'on ferait appel à ce pool qui récupérerait une connexion dispo. On utilisait ce principe en java pour accéder à une base Oracle (ds une autre vie)
Manu, si tu me lit, ça titillerait pas tes neurones ça pour rajouter ce type d'accès aux accès alternatifs ????
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Gégé
Roumegou Eric a écrit :
Pour m'éviter les problèmes d'index, je travaille avec des SGBD comme Oracle ou mySQL. C'est quoi les problèmes d'index ??
Effectivement, pas de problème avec Oracle. Mais dans le cadre d'une appli multi-bases, tu peux en avoir (MS-Access, FoxBase, SyBase).
Je travaille comme cela depuis très longtemps et je n'ais pas rencontré de pb.
Tant mieux si ton réseau est propre, qu'il tourne sur du 100BaseT et que tu ne passes pas par des liens bas débit.
Il faut dire que je n'ai jamais eu plus de 50 connectés en meme
temps sur une appli.
Il ne faut pas raisonner en nombre d'utilisateurs mais en requête sur la base (qui plus est les requêtes en écriture).
Roumegou Eric a écrit :
Pour m'éviter les problèmes d'index, je travaille avec des SGBD comme
Oracle ou mySQL. C'est quoi les problèmes d'index ??
Effectivement, pas de problème avec Oracle. Mais dans le cadre d'une
appli multi-bases, tu peux en avoir (MS-Access, FoxBase, SyBase).
Je travaille comme cela depuis très longtemps et je n'ais pas rencontré
de pb.
Tant mieux si ton réseau est propre, qu'il tourne sur du 100BaseT et que
tu ne passes pas par des liens bas débit.
Il faut dire que je n'ai jamais eu plus de 50 connectés en meme
temps sur une appli.
Il ne faut pas raisonner en nombre d'utilisateurs mais en requête sur la
base (qui plus est les requêtes en écriture).
Pour m'éviter les problèmes d'index, je travaille avec des SGBD comme Oracle ou mySQL. C'est quoi les problèmes d'index ??
Effectivement, pas de problème avec Oracle. Mais dans le cadre d'une appli multi-bases, tu peux en avoir (MS-Access, FoxBase, SyBase).
Je travaille comme cela depuis très longtemps et je n'ais pas rencontré de pb.
Tant mieux si ton réseau est propre, qu'il tourne sur du 100BaseT et que tu ne passes pas par des liens bas débit.
Il faut dire que je n'ai jamais eu plus de 50 connectés en meme
temps sur une appli.
Il ne faut pas raisonner en nombre d'utilisateurs mais en requête sur la base (qui plus est les requêtes en écriture).
Eric Demeester
dans (in) fr.comp.developpement.agl.windev, Roumegou Eric ecrivait (wrote) :
Bonsoir,
Gégé a émis l'idée suivante : > Peu importe le SGBD, dans tout traitement : tu ouvres la connexion, tu > requêtes et tu fermes.
Justement ça se discute ça ! En C/S, cela n'est pas franchement la technique de prédilection.
Sur un réseau local, utiliser des connexions persistantes se défend, encore que...
Par contre, dans un contexte web, j'hésite en ce moment à mettre au point cette technique car j'ai beaucoup de process en sleeping.
Dans un contexte web, il vaut mieux faire comme suggère Gégé, au point que chez la plupart des hébergeurs (je parle de MySQL), tu peux faire des pmysqlconnect() plutôt que des mysqlconnetc(), ça fonctionnera, mais la connexion sera refermée quand même dès la réponse à la requête renvoyée au navigateur.
Pour l'instant, je me connecte au sgbd et je déconnecte à la fermeture de session.
Tu le dis toi-même, tu as beaucoup de process en attente. Ils ne font rien, mais ils consomment quand même des ressources sur le serveur, en mémoire essentiellement. Si tu as beaucoup de personnes connectées simultanément, c'est un coup à écrouler la machine...
Mais je crains que la connexion à chaque requete soit trop impactante sur les temps de réponses.
Des expériences là dessus ?
Etant hébergeur, oui, j'en ai :)
Clairement, c'est transparent pour l'utilisateur et ça soulage le serveur. Ca induit en revanche des contraintes supplémentaires en termes de développement, car il faut promener pas mal de variables de session d'une page à l'autre, le serveur ne gardant du coup aucune trace des résultats renvoyés au client.
-- Eric
dans (in) fr.comp.developpement.agl.windev, Roumegou Eric
<UtilisezleLien@fin.msg> ecrivait (wrote) :
Bonsoir,
Gégé a émis l'idée suivante :
> Peu importe le SGBD, dans tout traitement : tu ouvres la connexion, tu
> requêtes et tu fermes.
Justement ça se discute ça !
En C/S, cela n'est pas franchement la technique de prédilection.
Sur un réseau local, utiliser des connexions persistantes se défend,
encore que...
Par contre, dans un contexte web, j'hésite en ce moment à mettre au
point cette technique car j'ai beaucoup de process en sleeping.
Dans un contexte web, il vaut mieux faire comme suggère Gégé, au point
que chez la plupart des hébergeurs (je parle de MySQL), tu peux faire
des pmysqlconnect() plutôt que des mysqlconnetc(), ça fonctionnera, mais
la connexion sera refermée quand même dès la réponse à la requête
renvoyée au navigateur.
Pour l'instant, je me connecte au sgbd et je déconnecte à la fermeture
de session.
Tu le dis toi-même, tu as beaucoup de process en attente. Ils ne font
rien, mais ils consomment quand même des ressources sur le serveur, en
mémoire essentiellement. Si tu as beaucoup de personnes connectées
simultanément, c'est un coup à écrouler la machine...
Mais je crains que la connexion à chaque requete soit trop
impactante sur les temps de réponses.
Des expériences là dessus ?
Etant hébergeur, oui, j'en ai :)
Clairement, c'est transparent pour l'utilisateur et ça soulage le
serveur. Ca induit en revanche des contraintes supplémentaires en termes
de développement, car il faut promener pas mal de variables de session
d'une page à l'autre, le serveur ne gardant du coup aucune trace des
résultats renvoyés au client.
dans (in) fr.comp.developpement.agl.windev, Roumegou Eric ecrivait (wrote) :
Bonsoir,
Gégé a émis l'idée suivante : > Peu importe le SGBD, dans tout traitement : tu ouvres la connexion, tu > requêtes et tu fermes.
Justement ça se discute ça ! En C/S, cela n'est pas franchement la technique de prédilection.
Sur un réseau local, utiliser des connexions persistantes se défend, encore que...
Par contre, dans un contexte web, j'hésite en ce moment à mettre au point cette technique car j'ai beaucoup de process en sleeping.
Dans un contexte web, il vaut mieux faire comme suggère Gégé, au point que chez la plupart des hébergeurs (je parle de MySQL), tu peux faire des pmysqlconnect() plutôt que des mysqlconnetc(), ça fonctionnera, mais la connexion sera refermée quand même dès la réponse à la requête renvoyée au navigateur.
Pour l'instant, je me connecte au sgbd et je déconnecte à la fermeture de session.
Tu le dis toi-même, tu as beaucoup de process en attente. Ils ne font rien, mais ils consomment quand même des ressources sur le serveur, en mémoire essentiellement. Si tu as beaucoup de personnes connectées simultanément, c'est un coup à écrouler la machine...
Mais je crains que la connexion à chaque requete soit trop impactante sur les temps de réponses.
Des expériences là dessus ?
Etant hébergeur, oui, j'en ai :)
Clairement, c'est transparent pour l'utilisateur et ça soulage le serveur. Ca induit en revanche des contraintes supplémentaires en termes de développement, car il faut promener pas mal de variables de session d'une page à l'autre, le serveur ne gardant du coup aucune trace des résultats renvoyés au client.
-- Eric
Daniel
Bonsoir, Gégé writes:
Roumegou Eric a écrit : > Justement ça se discute ça ! > En C/S, cela n'est pas franchement la technique de prédilection.
Bin si ! Et comme cela, tu t'évites bien des problèmes d'index. Parce que ouvrir la connexion au lancement de l'appli et la laisser ouverte, c'est pas terrible.
sur mysql que tu restes connecté ou pas, sur un réseau de bonne ou de mauvaise qualité il n'y a pas de problème d'index c'est un peu l'intéret de ce type de SGBD...
Pour revenir à la question de Manu P, soit effectivement il peut faire comme en Web et se déconnecte après chaque requête et dans ce cas pas de problème, sinon tu peux mettre en tache de fond un mysqlping qui va controler si le serveur est Ok et en même temps éviter la déconnexion... A priori Mysql n'envoit pas de signal pour dire que tu vas être déconnecté (tout du moins je n'ai rien trouvé dans ce sens dans les doc). Pour un fonctionnement en C/S tu peux regarder avec netstat le statut sur le port 3306, çà marche à chaque fois dès que ton serveur mysql est indisponible tu vois l'état passer de "Established" à "Wait..". Le problème de cette méthode est que si tu fonctionnes en client fin, il va être plus difficile de retrouver ces petits, quoique en cherchant il doit y avoir une solution -- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Roumegou Eric a écrit :
> Justement ça se discute ça !
> En C/S, cela n'est pas franchement la technique de prédilection.
Bin si ! Et comme cela, tu t'évites bien des problèmes d'index. Parce
que ouvrir la connexion au lancement de l'appli et la laisser ouverte,
c'est pas terrible.
sur mysql que tu restes connecté ou pas, sur un réseau de bonne ou de
mauvaise qualité il n'y a pas de problème d'index c'est un peu
l'intéret de ce type de SGBD...
Pour revenir à la question de Manu P, soit effectivement il peut faire
comme en Web et se déconnecte après chaque requête et dans ce cas pas
de problème, sinon tu peux mettre en tache de fond un mysqlping qui va
controler si le serveur est Ok et en même temps éviter la
déconnexion...
A priori Mysql n'envoit pas de signal pour dire que tu vas être
déconnecté (tout du moins je n'ai rien trouvé dans ce sens dans les
doc).
Pour un fonctionnement en C/S tu peux regarder avec netstat le statut
sur le port 3306, çà marche à chaque fois dès que ton serveur mysql
est indisponible tu vois l'état passer de "Established" à "Wait..".
Le problème de cette méthode est que si tu fonctionnes en client fin, il
va être plus difficile de retrouver ces petits, quoique en cherchant
il doit y avoir une solution
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Roumegou Eric a écrit : > Justement ça se discute ça ! > En C/S, cela n'est pas franchement la technique de prédilection.
Bin si ! Et comme cela, tu t'évites bien des problèmes d'index. Parce que ouvrir la connexion au lancement de l'appli et la laisser ouverte, c'est pas terrible.
sur mysql que tu restes connecté ou pas, sur un réseau de bonne ou de mauvaise qualité il n'y a pas de problème d'index c'est un peu l'intéret de ce type de SGBD...
Pour revenir à la question de Manu P, soit effectivement il peut faire comme en Web et se déconnecte après chaque requête et dans ce cas pas de problème, sinon tu peux mettre en tache de fond un mysqlping qui va controler si le serveur est Ok et en même temps éviter la déconnexion... A priori Mysql n'envoit pas de signal pour dire que tu vas être déconnecté (tout du moins je n'ai rien trouvé dans ce sens dans les doc). Pour un fonctionnement en C/S tu peux regarder avec netstat le statut sur le port 3306, çà marche à chaque fois dès que ton serveur mysql est indisponible tu vois l'état passer de "Established" à "Wait..". Le problème de cette méthode est que si tu fonctionnes en client fin, il va être plus difficile de retrouver ces petits, quoique en cherchant il doit y avoir une solution -- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Roumegou Eric
Eric Demeester a exposé le 20/10/2004 :
pmysqlconnect
Salut Eric,
Jamais entendu cette instruction et rien trouvé dans google. Tu es sûr de la syntaxe ?
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Eric Demeester a exposé le 20/10/2004 :
pmysqlconnect
Salut Eric,
Jamais entendu cette instruction et rien trouvé dans google.
Tu es sûr de la syntaxe ?
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Jamais entendu cette instruction et rien trouvé dans google. Tu es sûr de la syntaxe ?
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Manu Pavy
Roumegou Eric a fait part de :
Eric Demeester a exposé le 20/10/2004 :
pmysqlconnect
Salut Eric,
Jamais entendu cette instruction et rien trouvé dans google. Tu es sûr de la syntaxe ?
En php, il existe mysql_pconnect() (c'est à ca que Eric D faisait allusion je suppose) qui connecte le temps du chargement de la page (ou exécution du script).
Mais l'équivalent en W-Langage, je ne connais pas.
En tout cas, je vois que la question fait débat et que les réponses n e sont pas unanimes. Je vais regarder les différentes solutions, bien que je n'ai pas très bien compris ce point :
Le problème de cette méthode est que si tu fonctionnes en client fi n, il va être plus difficile de retrouver ces petits, quoique en cherchant il doit y avoir une solution
Manu
Roumegou Eric a fait part de :
Eric Demeester a exposé le 20/10/2004 :
pmysqlconnect
Salut Eric,
Jamais entendu cette instruction et rien trouvé dans google.
Tu es sûr de la syntaxe ?
En php, il existe mysql_pconnect() (c'est à ca que Eric D faisait
allusion je suppose) qui connecte le temps du chargement de la page (ou
exécution du script).
Mais l'équivalent en W-Langage, je ne connais pas.
En tout cas, je vois que la question fait débat et que les réponses n e
sont pas unanimes. Je vais regarder les différentes solutions, bien que
je n'ai pas très bien compris ce point :
Le problème de cette méthode est que si tu fonctionnes en client fi n, il
va être plus difficile de retrouver ces petits, quoique en cherchant
il doit y avoir une solution
Jamais entendu cette instruction et rien trouvé dans google. Tu es sûr de la syntaxe ?
En php, il existe mysql_pconnect() (c'est à ca que Eric D faisait allusion je suppose) qui connecte le temps du chargement de la page (ou exécution du script).
Mais l'équivalent en W-Langage, je ne connais pas.
En tout cas, je vois que la question fait débat et que les réponses n e sont pas unanimes. Je vais regarder les différentes solutions, bien que je n'ai pas très bien compris ce point :
Le problème de cette méthode est que si tu fonctionnes en client fi n, il va être plus difficile de retrouver ces petits, quoique en cherchant il doit y avoir une solution
