Je cherche une explication logique (et donc une piste) pour résoudre un
problème jusque là insoluble.
Soit Prog.mdb (sur des postes en local C:) et DATA sur le réseau. (jusqu'ici
ça va !)
PROG fait appel à des tables liés chez DATA (ça va toujours !)
Si je lance 1 PROG, pas de problème.
Si je lance 2 PROG, gros problème ! (performance : 48 s pour ouvrir une
simple Table sur ce poste !)
En résumé :
1- Si je lance la table directement dans DATA (en me mettant sur le réseau)
: ouverture immédiate.
2- Si j'ouvre la table sur 1 PROG : 3 s pour ouvrir cette table
3- Si j'ouvre la table sur 2 PROG : 48s sur le second poste.
Je ne parle même pas de formulaire basée sur une requête !
Je ne vois pas où chercher pour résoudre ce problème, alors vous les Pros,
si vous avez la solution, je vous bénis.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Anor
Bonjour NetChris
Dans ton explication, on ne voit pas si :
48 secondes, c'est pour le deuxième poste qui se connecte ou si c'est toujours le même poste qui se connecte.
Si ton poste 2 (2ème poste connecté) est lent et que poste 1 se déconnecte et que poste 2 reste tout seul, c'est mieux ?
Besoin d'identifier : si c'est *un poste particulier* en cause si c'est un problème de partage de ressource si une fois le poste 2 connecté, le poste 1 est aussi lent que le 2.
As tu une procédure de rattachement de tables automatique ?
@+ Arnaud
ps : cohabitation avec des OS hétérogènes pas glop.... (et je crains le jour où ça va m'arriver ...)
ps : rn recherchant dans les archives avec des mots clés comme performances, lenteur, réseau etc.. de nombreuses pistes sont données...
| Salut à tous ! | | Access 2000, postes sous W98, W2000, XP. | | Je cherche une explication logique (et donc une piste) pour résoudre | un problème jusque là insoluble. | | Soit Prog.mdb (sur des postes en local C:) et DATA sur le réseau. | (jusqu'ici ça va !) | | PROG fait appel à des tables liés chez DATA (ça va toujours !) | | Si je lance 1 PROG, pas de problème. | Si je lance 2 PROG, gros problème ! (performance : 48 s pour ouvrir | une simple Table sur ce poste !) | | En résumé : | 1- Si je lance la table directement dans DATA (en me mettant sur le | réseau) || ouverture immédiate. | 2- Si j'ouvre la table sur 1 PROG : 3 s pour ouvrir cette table | 3- Si j'ouvre la table sur 2 PROG : 48s sur le second poste. | | Je ne parle même pas de formulaire basée sur une requête ! | | Je ne vois pas où chercher pour résoudre ce problème, alors vous les | Pros, si vous avez la solution, je vous bénis. | | Chris
Bonjour NetChris
Dans ton explication, on ne voit pas si :
48 secondes, c'est pour le deuxième poste qui se connecte
ou si c'est toujours le même poste qui se connecte.
Si ton poste 2 (2ème poste connecté) est lent et que poste 1
se déconnecte et que poste 2 reste tout seul, c'est mieux ?
Besoin d'identifier :
si c'est *un poste particulier* en cause
si c'est un problème de partage de ressource
si une fois le poste 2 connecté, le poste 1 est aussi lent que le 2.
As tu une procédure de rattachement de tables automatique ?
@+
Arnaud
ps : cohabitation avec des OS hétérogènes pas glop....
(et je crains le jour où ça va m'arriver ...)
ps : rn recherchant dans les archives avec des mots clés comme performances, lenteur, réseau
etc..
de nombreuses pistes sont données...
| Salut à tous !
|
| Access 2000, postes sous W98, W2000, XP.
|
| Je cherche une explication logique (et donc une piste) pour résoudre
| un problème jusque là insoluble.
|
| Soit Prog.mdb (sur des postes en local C:) et DATA sur le réseau.
| (jusqu'ici ça va !)
|
| PROG fait appel à des tables liés chez DATA (ça va toujours !)
|
| Si je lance 1 PROG, pas de problème.
| Si je lance 2 PROG, gros problème ! (performance : 48 s pour ouvrir
| une simple Table sur ce poste !)
|
| En résumé :
| 1- Si je lance la table directement dans DATA (en me mettant sur le
| réseau)
|| ouverture immédiate.
| 2- Si j'ouvre la table sur 1 PROG : 3 s pour ouvrir cette table
| 3- Si j'ouvre la table sur 2 PROG : 48s sur le second poste.
|
| Je ne parle même pas de formulaire basée sur une requête !
|
| Je ne vois pas où chercher pour résoudre ce problème, alors vous les
| Pros, si vous avez la solution, je vous bénis.
|
| Chris
48 secondes, c'est pour le deuxième poste qui se connecte ou si c'est toujours le même poste qui se connecte.
Si ton poste 2 (2ème poste connecté) est lent et que poste 1 se déconnecte et que poste 2 reste tout seul, c'est mieux ?
Besoin d'identifier : si c'est *un poste particulier* en cause si c'est un problème de partage de ressource si une fois le poste 2 connecté, le poste 1 est aussi lent que le 2.
As tu une procédure de rattachement de tables automatique ?
@+ Arnaud
ps : cohabitation avec des OS hétérogènes pas glop.... (et je crains le jour où ça va m'arriver ...)
ps : rn recherchant dans les archives avec des mots clés comme performances, lenteur, réseau etc.. de nombreuses pistes sont données...
| Salut à tous ! | | Access 2000, postes sous W98, W2000, XP. | | Je cherche une explication logique (et donc une piste) pour résoudre | un problème jusque là insoluble. | | Soit Prog.mdb (sur des postes en local C:) et DATA sur le réseau. | (jusqu'ici ça va !) | | PROG fait appel à des tables liés chez DATA (ça va toujours !) | | Si je lance 1 PROG, pas de problème. | Si je lance 2 PROG, gros problème ! (performance : 48 s pour ouvrir | une simple Table sur ce poste !) | | En résumé : | 1- Si je lance la table directement dans DATA (en me mettant sur le | réseau) || ouverture immédiate. | 2- Si j'ouvre la table sur 1 PROG : 3 s pour ouvrir cette table | 3- Si j'ouvre la table sur 2 PROG : 48s sur le second poste. | | Je ne parle même pas de formulaire basée sur une requête ! | | Je ne vois pas où chercher pour résoudre ce problème, alors vous les | Pros, si vous avez la solution, je vous bénis. | | Chris
Anor
Bonjour NetChris
il faut identifier le fautif :.
Soit c'est le paramétrage des postes qui est mal fait (OS déjà hétéroclytes) Soit c'est le réseau soit c'est le serveur (antivirus, etc...) soit c'est ta base etc...etc...
Tu peux essayer avec une de tes tables dans une base neuve et 1 formulaire. Tu fractionnes et tu testes : pb chez le client, je suis d'accord....
Fais le test entre 2 machines de même OS pour y aller par élimination !! Il y a des dizaines et des dizaines de manières de faire pour remonter à la source d'une défaillance, trouver une cause ou inhiber les hypothèses.
Mais toutes ces méthodes viennent à l'esprit lorsqu'on est *devant* le problème.
Commence par t'inspirer des "dossiers" suivants : http://groups.google.com/groups?hl=fr&lr=&ie=UTF-8&selm=uAyK9yE0CHA.1656%40TK2MSFTNGP09 et http://access.seneque.free.fr/optimisation.htm
Mais je suppose que tu l'as déjà fait puisque ce n'est pas la première fois que tu postes pour des problèmes de lenteur.
| Bonnes questions ! | | 48s c'est pour le second poste (le A ou le B, du moment que c'est le | second). CAD que l'on peut intervertir 'LES' postes pour constater le | même problème. | Aucun module activité (ré-attache de tables ou quoi que ce soit. | Puisque je constate le probleme en double-cliquant sur une table | | Ex: table 'CLIENTS' | directement dans DATA, ouverture de CLIENTS par double-clic sur la | table = 0 s | directement dans PROG 1 (pas d'autres PROG ouverts) = 3s | directement dans PROG 2 (PROG 1 ouvert) = 48 s | | donc aucun formulaire ouvert, ni module, ni macro ! Que double-clic | sur une table pour l'ouvrir. | | J'ai consulté les archives mais rien qui puisse me donner une piste | valable, pour un test aussi basique. | J'ai essayé de copier tous les éléments dans un nouveau MDB (pensant | que le premier était endommagé) sans succès. | Toujours pas de pistes ........... hummmm | | Je passe pour un C.... chez mon client ! |
Bonjour NetChris
il faut identifier le fautif :.
Soit c'est le paramétrage des postes qui est mal fait (OS déjà hétéroclytes)
Soit c'est le réseau
soit c'est le serveur (antivirus, etc...)
soit c'est ta base
etc...etc...
Tu peux essayer avec une de tes tables dans une base neuve et 1 formulaire.
Tu fractionnes et tu testes : pb chez le client, je suis d'accord....
Fais le test entre 2 machines de même OS pour y aller par élimination !!
Il y a des dizaines et des dizaines de manières de faire pour remonter à la source
d'une défaillance, trouver une cause ou inhiber les hypothèses.
Mais toutes ces méthodes viennent à l'esprit lorsqu'on est *devant* le problème.
Commence par t'inspirer des "dossiers" suivants :
http://groups.google.com/groups?hl=fr&lr=&ie=UTF-8&selm=uAyK9yE0CHA.1656%40TK2MSFTNGP09
et
http://access.seneque.free.fr/optimisation.htm
Mais je suppose que tu l'as déjà fait puisque ce n'est pas la première fois que tu postes pour
des problèmes de lenteur.
| Bonnes questions !
|
| 48s c'est pour le second poste (le A ou le B, du moment que c'est le
| second). CAD que l'on peut intervertir 'LES' postes pour constater le
| même problème.
| Aucun module activité (ré-attache de tables ou quoi que ce soit.
| Puisque je constate le probleme en double-cliquant sur une table
|
| Ex: table 'CLIENTS'
| directement dans DATA, ouverture de CLIENTS par double-clic sur la
| table = 0 s
| directement dans PROG 1 (pas d'autres PROG ouverts) = 3s
| directement dans PROG 2 (PROG 1 ouvert) = 48 s
|
| donc aucun formulaire ouvert, ni module, ni macro ! Que double-clic
| sur une table pour l'ouvrir.
|
| J'ai consulté les archives mais rien qui puisse me donner une piste
| valable, pour un test aussi basique.
| J'ai essayé de copier tous les éléments dans un nouveau MDB (pensant
| que le premier était endommagé) sans succès.
| Toujours pas de pistes ........... hummmm
|
| Je passe pour un C.... chez mon client !
|
Soit c'est le paramétrage des postes qui est mal fait (OS déjà hétéroclytes) Soit c'est le réseau soit c'est le serveur (antivirus, etc...) soit c'est ta base etc...etc...
Tu peux essayer avec une de tes tables dans une base neuve et 1 formulaire. Tu fractionnes et tu testes : pb chez le client, je suis d'accord....
Fais le test entre 2 machines de même OS pour y aller par élimination !! Il y a des dizaines et des dizaines de manières de faire pour remonter à la source d'une défaillance, trouver une cause ou inhiber les hypothèses.
Mais toutes ces méthodes viennent à l'esprit lorsqu'on est *devant* le problème.
Commence par t'inspirer des "dossiers" suivants : http://groups.google.com/groups?hl=fr&lr=&ie=UTF-8&selm=uAyK9yE0CHA.1656%40TK2MSFTNGP09 et http://access.seneque.free.fr/optimisation.htm
Mais je suppose que tu l'as déjà fait puisque ce n'est pas la première fois que tu postes pour des problèmes de lenteur.
| Bonnes questions ! | | 48s c'est pour le second poste (le A ou le B, du moment que c'est le | second). CAD que l'on peut intervertir 'LES' postes pour constater le | même problème. | Aucun module activité (ré-attache de tables ou quoi que ce soit. | Puisque je constate le probleme en double-cliquant sur une table | | Ex: table 'CLIENTS' | directement dans DATA, ouverture de CLIENTS par double-clic sur la | table = 0 s | directement dans PROG 1 (pas d'autres PROG ouverts) = 3s | directement dans PROG 2 (PROG 1 ouvert) = 48 s | | donc aucun formulaire ouvert, ni module, ni macro ! Que double-clic | sur une table pour l'ouvrir. | | J'ai consulté les archives mais rien qui puisse me donner une piste | valable, pour un test aussi basique. | J'ai essayé de copier tous les éléments dans un nouveau MDB (pensant | que le premier était endommagé) sans succès. | Toujours pas de pistes ........... hummmm | | Je passe pour un C.... chez mon client ! |
Anor
Bonjour NetChris
Le serveur de fichiers, il tourne sous quoi ? WinNT ?
On mon avis, ça se passe plutôt de ce côté là car si 3 accès simultanés à une même base ne contenant que des tables ça fait ça, il faut regarder du côté du serveur ou de son antivirus.
| Salut Anor, | | Je reviens de chez le client sans avoir trouver de solutions | | J'ai fait le test sur 3 postes en 98. | | Sans passer par les formulaires. Uniquement une table (5000 enregs) | | Même problème. Il me reste à tester le dernier conseil de François, | notre | cher ami Belge. avec le formulaire DUMMY. Le reste, je l'ai appliqué, | avec | quelques améliorations, mais des performances desastreuses sur | d('autres | points). | | Quant aux conseils de Raymond, je l'ai ai appliqué dès le début. | | Je coince !!!!!!!! |
Bonjour NetChris
Le serveur de fichiers, il tourne sous quoi ? WinNT ?
On mon avis, ça se passe plutôt de ce côté là car
si 3 accès simultanés à une même base ne contenant
que des tables ça fait ça, il faut regarder du côté du serveur
ou de son antivirus.
| Salut Anor,
|
| Je reviens de chez le client sans avoir trouver de solutions
|
| J'ai fait le test sur 3 postes en 98.
|
| Sans passer par les formulaires. Uniquement une table (5000 enregs)
|
| Même problème. Il me reste à tester le dernier conseil de François,
| notre
| cher ami Belge. avec le formulaire DUMMY. Le reste, je l'ai appliqué,
| avec
| quelques améliorations, mais des performances desastreuses sur
| d('autres
| points).
|
| Quant aux conseils de Raymond, je l'ai ai appliqué dès le début.
|
| Je coince !!!!!!!!
|
Le serveur de fichiers, il tourne sous quoi ? WinNT ?
On mon avis, ça se passe plutôt de ce côté là car si 3 accès simultanés à une même base ne contenant que des tables ça fait ça, il faut regarder du côté du serveur ou de son antivirus.
| Salut Anor, | | Je reviens de chez le client sans avoir trouver de solutions | | J'ai fait le test sur 3 postes en 98. | | Sans passer par les formulaires. Uniquement une table (5000 enregs) | | Même problème. Il me reste à tester le dernier conseil de François, | notre | cher ami Belge. avec le formulaire DUMMY. Le reste, je l'ai appliqué, | avec | quelques améliorations, mais des performances desastreuses sur | d('autres | points). | | Quant aux conseils de Raymond, je l'ai ai appliqué dès le début. | | Je coince !!!!!!!! |
