Donc, pour améliorer mon application et avoir moins de pb lors de connection simultanée, je souhaite creer une seule connection à ma base et la stocker ds une variable d'application, parfois ca marche (la majorité) ms g une merde et je sais pas quoi...
 
On dirait qu'il perd une partie des infos, ms tt semble etre bon, je me demande si c'est pas le fait de passer par une var d'application qui fout la merde, c'est peut etre pas possible...
 
 
 
Si qqn a dejà tenté l'experience

Tu l'as créée comment, ta connexion ?
 
Pourrais-tu filer la trace d'erreur exacte, steuplé.

Application("ConnectionSTring" ) = sBbase;
Application("UserTemp" ) = sLogin;
Application("MdpTemp" ) = sMotDePasse;
var objetConnection= Server.CreateObject("ADODB.Connection" )
Application("ConnectionBase" ) = Server.CreateObject("ADODB.Command" )
objetConnection.Open(sBbase, sLogin, sMotDePasse)
Application("ConnectionBase" ).ActiveConnection = objetConnection
 
Pr la trace d'erreur il me dit que la connection est fermée, alors que la majorité du tps, ça passe

Je viens de chopper ça ds le techNet et il conseille de na pas le faire, ç po rentable
 
Caching ADO Connections is usually a bad strategy. If one Connection object is stored in the Application object and used on all pages, then all pages will contend for use of this connection. If the Connection object is stored in the ASP Session object, then a database connection will be created for every user. This defeats the benefits of connection pooling and puts unnecessarily high stress on both the Web server and the database.
Instead of caching database connections, create and destroy ADO objects on every ASP page that uses ADO. This is efficient because IIS has database connection pooling built in. More accurately, IIS automatically enables OLEDB and ODBC connection pooling. This ensures that creating and destroying connections on each page will be efficient.
Since connected recordsets store a reference to a database connection, it follows that you should not cache connected recordsets in the Application or Session objects. However, you can safely cache disconnected recordsets, which don?t hold a reference to their data connection. To disconnect a recordset, take the following two steps:
    Set rs = Server.CreateObject("ADODB.RecordSet" )
   rs.CursorLocation = adUseClient  ' step 1
 
   ' Populate the recordset with data
   rs.Open strQuery, strProv
 
   ' Now disconnect the recordset from the data provider and data source
   rs.ActiveConnection = Nothing    ' step 2
 
More information about connection pooling can be found in the ADO and SQL Server references.  

azra28 > En effet, j'ai déjà lu ce genre d'articles sur msdn. Mais sur msdn toujours, j'ai aussi lu l'autre son de cloche.
 
Grossomodo, il faut comparer les objets de connection à des taxis. C'est exactement la réprésentation physique de la problématique.
 
Tu arrives à Orly. Tu dois te rendre à une zone d'embarquement, tu attends un taxi qui t'emmène de l'entrée à la zone..
 
C'est exactement une page qui se charge sur le site et qui cherche des infos dans la base de données :
 
-> S'il y a très peu d'utilisateurs, il ne faut pas laisser le moteur du taxi tourner toute la journée pour deux passagers dans la journée. Donc, niveau ADO, pas de variable d'application.
-> S'il y a régulièrement des utilisateurs qui viennent, en nombre modéré, un taxi qui attends le moteur en marche tout le temps est ce qu'il y a de mieu : immédiatement près à démarrer, et jamais de surchagé (pas plus de 3 personnes à la fois). Donc une variable d'application chargée en parmanance et partagée entre les utilisateurs est ce qu'il y a de mieu.
-> Si tu as des pics de 80 passagers d'un coup (genre arrivée d'un bus de touristes), le taxi seule va mettre des heures à faire des allez-retours. Il faut donc prévoir d'affrêter autant de taxi qu'il y a de passagers. Donc pas de variable d'application
 
On vois donc qu'entre une charge très élevée et très faible, il faut la même solution.
Mais pour une charge moyenne et régulière, la solution des variables d'applications est la plus adaptée : économie de ressources et de temps.
 
En fait, l'article en question déconseille cette solution car cette solution à de sérieux problèmes de montée en charge. Mais il faut voir aussi à partir de quel moment... Sur un serveur qui fait 1000 hits à la minute, je suis pas certain que ça suffise pour observer une baisse de perfs.
 
Sinon, pour les variables de session, la problématique se pose entre taxi et voiture privée.
-> Est-ce que l'utilisateur à besoin tout le temps de se déplacer ou non ? En effet, si l'utilisateur exécute deus requêtes durant les 10 minutes de sa visite, c'est idiot qu'il ait une connection à la base disponible en permanance.
Par contre, si dans chaque page tu fais des requêtes, c'est idiot de recréer une connection à chaque page... C'est comme si un facteur devait appeler un taxi à chaque fois qu'il change de rue lors de sa tournée... C'est mieu qu'il ait sa voiture de fonction avec lui

Voilà qqn qui sait expliquer correctement le spooling et je t'en remercie ms g laissé tomber, je cré une nvelle connection pr chaque requete et puis merde

OK
 
De toute façon, ADO fait le boulot de conserver la connection active et de la partager, sauf qu'ils s'adapte en fonction de la montée en charge. Donc au final ça change pas grand chose

c vrai que des fois, quand je relis les exemples que je donne, je me dis que j'ai raté ma vocation de prof