Salut à tous,
 
j'ai un gros pépin avec une base access, c'est une base qui peut être attaquée à tout moment, par plusieurs pages...
 
J'ai essayé de tout faire au mieux, j'utilise des curseurs par défaut pour mes recordsets, je me connecte au dernier moment, me déconnecte le plus tôt possible... Mais il y a quand même beaucoup de plantages du type : Erreur non spécifiée ou fichier en cours d'utilisation.
 
Comment faire pour réduire, sinon éliminer ces erreurs. J'ai résussi à en réduire la fréquence grâce à pas mal d'optimisations mais ça plante toujours trop.
 
Quels sont tous les p'tits trucs qui pourraient me sauver la vie ??

[edit]--Message édité par duch--[/edit]

Tu as essayé de passer a SQL Server en échangeant du XML ???

sacré déconneur guru
 
sql server c'est trop cher
 
 
t'as pas des conseils (au lieu de dire des conneries )

Caramba ye souis demaske !
 
Plus sérieusement comment accèdes tu a la base ADO + ODBC ou ADO + OLEDB ? Si tu ne le fais pas utilises plutot le provider OLEDB ca réduira un peu les ressources utilisées pour l'accès a la base.
 
Sinon avant d'aller plus loin as tu pu déterminer un déroulement menant à l'erreur ?

je pense pas que ce soit un problème d'optimisation....
pour cela tu peux esayer en local avec pws comme cela tu seras seul....
 
C'est surement un probleme de lecture de tes données, un truc dans le genre...

voilà un exemple de recordset :  
 
set rs = Server.CreateObject("ADODB.Recordset" )
rs.ActiveConnection = "dsn=mon_dsn;"
rs.Source = sql
rs.CursorType = 0 ' adOpenForwardOnly
rs.CursorLocation = 2
rs.Open
 
avouer qu'y'a pas + simple
 
ça changerait quelque chose si je rajoutais rs.LockType = 1 ' adLockReadOnly (j(crois pas c'est la valeur par défaut)
 
 
et un exemple de connexion :  
 
dim cnx
 
set cnx = Server.CreateObject("ADODB.Connection" )  
cnx.Open = "dsn=mon_dsn;"  
 
cnx.Execute = "INSERT into mabase (champ) VALUES ( '"& Request.form("valeur" ) & "')"
 
cnx.close  
set cnx = nothing
 
pareil on peux difficilement faire plus simple

Tu fais comme j'ai fait sur mon site :
 
Il vaut mieu que pour chaque personne il y aie une connexion ouverte en permanence plutôt que des cnx qui s'ouvrent et se ferment toutes les 2 ms...
 
Donc...
 
Dans le global.asa :
 
<SCRIPT LANGUAGE=VBScript RUNAT=Server>
sub Application_OnStart
 Application.Lock
 Application("DSN" ) ="Chaine de connection à la base"
 Application.UnLock
end sub
 
sub Session_OnStart
 Set session("CNX" ) = Server.CreateObject("ADODB.Connection" )
 session("CNX" ).Open Application("DSN" )
end sub
 
Sub Session_OnEnd
 session("CNX" ).close
 set session("CNX" ) = nothing
end sub
</SCRIPT>
 
Ensuite, dans un fichichier include '/include/cnx.asp'
 
<%
if isEmpty(Session("CNX" )) then
 Set Session("CNX" ) = Server.CreateObject("ADODB.Connection" )
 Session("CNX" ).Open Application("DSN" )
elseif Session("CNX" ).state <> 1 then
 Session("CNX" ).Open Application("DSN" )
end if
set cnx = Session("CNX" )
%>
 
Ensuite, dans toutes tes pages, pour utiliser la BDD :
 
<%@ Language=VBScript %>
<!-- #INCLUDE FILE="include/cnx.asp" -->
<%
sqlFen = "SELECT ... FROM ..."
dim rs
set rs = server.CreateObject("ADODB.Recordset" )
set rs.ActiveConnection = session("CNX" )
rs.CursorType = 0 ' adOpenForwardOnly
rs.LockType = 1  ' adLockReadOnly
rs.Open sqlFen
...
rs.close
set rs = nothing
%>
 
PS: N'oublie pas aussi que tu peux réutiliser le même recordset pour faire plusieurs requêtes...
 
Ex:
 
sqlFen = "SELECT ... FROM ..."
dim rs
set rs = server.CreateObject("ADODB.Recordset" )
set rs.ActiveConnection = session("CNX" )
rs.CursorType = 0 ' adOpenForwardOnly
rs.LockType = 1  ' adLockReadOnly
rs.Open sql
...
rs.close
sql2 = "SELECT ... FROM ..."
rs.Open sql2
...
rs.close
set rs = nothing

Guru a écrit a écrit : Caramba ye souis demaske !   Plus sérieusement comment accèdes tu a la base ADO + ODBC ou ADO + OLEDB ? Si tu ne le fais pas utilises plutot le provider OLEDB ca réduira un peu les ressources utilisées pour l'accès a la base.   Sinon avant d'aller plus loin as tu pu déterminer un déroulement menant à l'erreur ?

 
j'utilise un DSN tout con
 
pour le déroulement conduisant à l'erreur, c'est aléatoire, une fois ça marche, une fois ça marche pas, et puis à des moments ça marche tout le temps, je pense vraiment que c'est parce que ma base encaisse pas plusieurs connexions.

 
Rhââââââaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa !!!!!!!!!!!
 
Gros cochon !
 
Là, tu crées une connection à chaque fois que tu créer un reccordset !!!!!
 
toujours créer la connection à par dans un objet "ADODB.Connection" !!!

Magicbuzz > j'te reconnais bien là, ça fait plaisir de te revoir après tout ce temps.
 
ça marche vraiement mieux de laisser une connexion ouverte tout le temps, ça parait bizarre ??
 
merci pour le tuyau pour les recordsets mais j'utilise toujours un seul rs par page.

MagicBuzz a écrit a écrit :     Rhââââââaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa !!!!!!!!!!!   Gros cochon !   Là, tu crées une connection à chaque fois que tu créer un reccordset !!!!!   toujours créer la connection à par dans un objet "ADODB.Connection" !!!

 
bah oui mais si j'utilise qu'un seul rs dans ma page ça doit pas changer grand chose

Quel type de charge dois tu gerer ?
Car de toute maniere ouvrir une connection pour chaque user peut ne pas etre viable si tu as mille utilisateurs qui peuvent recourir à la base en meme temps ...

Le fait de conserver la cnx ouverte en permanence à deux avantages :
 
Tu n'oublies jamais de la fermer
Tu n'en crées jamais plusieurs par page
 
En gros niveau code, c'est plus simple
 
Secondo, oui, car ça évite au serveur de passer son temps à ouvrir et fermer des connections (accès à la base de données pour rien) et ça bouffe bien moins de mémoire.

non j'ai pas mille users en même temps, mais y'a environ 2000 connexions par jour sur le site.

A tout hasard tu t'es bien assuré que le DSN n'ouvre pas la base access en Exclusif ?
 
Sinon concernant les connexions, il s'avère plus performant de garder des connexions a la base ouvertes si les utilisateurs font souvent des requêtes cela évitera de multiplier l'overhead du a l'instanciation d'objets. Il est préférable d'éviter les instanciations implicites.

[edit]--Message édité par Guru--[/edit]

MagicBuzz a écrit a écrit : Le fait de conserver la cnx ouverte en permanence à deux avantages :   Tu n'oublies jamais de la fermer Tu n'en crées jamais plusieurs par page   En gros niveau code, c'est plus simple   Secondo, oui, car ça évite au serveur de passer son temps à ouvrir et fermer des connections (accès à la base de données pour rien) et ça bouffe bien moins de mémoire.

 
 
Je te fais confiance magic, mais j'ai jamais entendu parler de ça, vous confirmer les autres?

Non, ça tu t'en fout...
Avec un liens ODBC, que tu aie 1 ou 100 000 cnx en même temps à la base, IIS n'en ouvre réellement qu'une qu'il partage ensuite.
Le faire de la laisser active en permance permet par contre de faire une énorme économie d'accès à la base. Car en affet à chaque ouverture/fermeture d'une connection, il y a un accès au fichier access... et c'est ça qui plante.

 
point un : tu vois ça où
 
point 2 : ça confirme ce que dit magic??

Mon guru que j'ai sous la main me dit que le pooling ADO n'est pas irréprochable ... Et c pour cela que je pense à la charge.
 
Les acces à la base ne sont que de la lecture ?

Sinon, Duch, c'est koi ton site ?
 
Parceque je peut t'herberger à la limite si vraiment ça chie trop...
 
Mon Serveur est sous MS SQL 2000, et niveau montée en charger, pas de problème

Ben tu vois la première proposition que je t'ai faite elle est bonne
 
Regardes dans les propriétés de ton DSN.

ça dépends des tables sur certaines, je ne fait que lire et sur d'autres, je lis et j'écris
 
sinon j'ai vérifié, la base n'est pas en exclusif
 
 
sinon y'a pas des trucs à changer dans les options avancées du DSN?

[edit]--Message édité par duch--[/edit]

Bon sinon, dernière question :  
 
si on a deux "applications" différentes sur un site, mais où l'utilisateur peut passer de l'une à l'autre, c'est quoi le mieux, une seule base ou deux bases??

Pour l'ecriture il faut du temps reel ou tu peux avoir une attente ... en vue d'etablir un objet tampon et lui seul accede à la base ...
 
pour moi les erreurs doivent plutot provenir de la cohabitation ecrire et lire ... m'enfin moi je suis pour la solution de magicbuzz SQL SERVER ... puis quand tu auras muri XML.  

temps réel ou pas c'est pas très grave, m'enfin je pense qu'en appliquant tous les tuyaux, je devrais pouvoir m'en sortir.
 
j'en ai pour 2 ans c'est tout
 
Comment éviter le blème lecture/écriture, sachant que visiblement le blème ne se pose qu'à la lecture (remarque à la l'écriture je peux pas vérifier car ça se passe dans un shockwave)
 
Merci à tous

[edit]--Message édité par duch--[/edit]

Serais tu en train de nous dire que d'un coté ton ASP va pomper les donnée via ADO/ODBC dans ta base et que d'un autre coté Shockwave va écrire directement des données dans la même base ?

non non, les deux passent par ASP, mais oui effectivement d'un côté quelqu'un peut être en train de visualiser les données pendant que quelqu'un d'autre écrit des données, c'est ça qui est drôle
 
mais comme mes rs sont en readonly ça devrait aller. non?

[edit]--Message édité par duch--[/edit]

Magicbuzz > je vois dans ta méthode que tu utilises une variable de session, comment fais-tu qd les cookies sont désativés??

Généralement, en niveau "standard" de désactivation des cookies, le navigateur laisse passer les cookies de session.
 
Jusqu'à présent, jamais eu de problème, même avec des gros paranos.

sinon y'a pas une autre soluce, parce que des paranos, moi j'm'en tape plein. Et j'suis pas sûr que ça pose pas de blème avec Netscape.

Mon site marche très bien avec NetScape 3.0 et Mosaïque
 
Donc à partir de là...

PS: Deplus, y'a un gars au boulot qui a installé un soft à la con qui permet de désactiver les redirects, scripts, cookies...
 
Truc de taré !
 
Les sessions marchaient encore.

bah arrête, il marche que avec IE 5.5
 
Non j'sais pas, de toute façon y'a pas d'autre soluce pour stocker la chaine de déconnexion.

c'est pas la chaîne de cnx !
 
La chaîne de CNX, c'est Application("DSN" )
 
Non, c'est réellement l'objet connection que tu mets en session.

Et c'est pas vrai mon site il marche très bien avec NS 3.0 maintenant
 
Je l'ai tout bien fait évolué
 
Il marche même sur les téléphone Wap

Pardon Lucile pour la confusion, mais ça ne change pas le blème, il faut toujours mettre un truc en session, et ça passe pas partout me semble-t-il.
 
Ah! damned, Lucile c'est Magic déguisé, j'm'en rappelais plus.

[edit]--Message édité par duch--[/edit]

mise à part NS/IE 2.0 et Mosaïc 1.0 les sessions passent partout !
 
Même Lynx les accepte

Bon ben si tu le dis.
 
j'vais essayé d'aller sur ton site avec un gros niveau de sécu pour voir...
 
de toute façon avec le niveau de secu maxi, y'a plus rien qui marche alors
 
 
guru : Bon sinon, dernière question :  
 
si on a deux "applications" différentes sur un site, mais où l'utilisateur peut passer de l'une à l'autre, c'est quoi le mieux, une seule base ou deux bases??
 
 
et aussi
 
Comment éviter le blème lecture/écriture, sachant que visiblement le blème ne se pose qu'à la lecture (remarque à la l'écriture je peux pas vérifier car ça se passe dans un shockwave)  
 
et aussi
 
non non, les deux passent par ASP, mais oui effectivement d'un côté quelqu'un peut être en train de visualiser les données pendant que quelqu'un d'autre écrit des données, c'est ça qui est drôle  
 
mais comme mes rs sont en readonly ça devrait aller. non?
 
 
sinon tu es d'accord avec magic en ce qui concerne les sessions?

[edit]--Message édité par duch--[/edit]

C'était quoi la question ?

Les variables de sessions qui utilisent les cookies.
 
Et je dis que oui, mais c'est pas grave, car vu que c'est un cookie à part, ça ne pose pas de problème dans 99% des cas.