La lenteur de mon application la rend quasi inutilisable
sans que je sache pourquoi. Il s'agit d'une petite
application avec tables liees d'environ 1Mo et du code VBA
pour les forms et les reports.
Lorsque que je travaille sur une forme pour la modifier,
la sauvegarde ou le passage du mode Design View au mode
Form View prend de 1 a 2 minutes, meme si je n'ai fait
aucune modification ?!
Les elements de mon application sont sur un reseau Windows
2000.
Que faire ?
Merci d'avance
ACS INFORMATIQUE 122,rue du Château d'orgemont 49000 ANGERS Tel: 02 41 68 42 36 Fax: 02 41 68 42 48 ---------------------------------------------------------------------------- --------------------- "JJF" a écrit dans le message de news:bha3ln$aru$
Hello, Il faut mettre tous les éléments de ton application en local (formulaires, états, codes, queries, etc..). Il faut laisser sur le réseau que les tables partagées qui sont ensuite attachée dans ton application. C'est ton réseau qui est trop lent. Ciao JJ "Marcis" a écrit dans le message de news: 0a5101c3609c$578e3cd0$
La lenteur de mon application la rend quasi inutilisable sans que je sache pourquoi. Il s'agit d'une petite application avec tables liees d'environ 1Mo et du code VBA pour les forms et les reports. Lorsque que je travaille sur une forme pour la modifier, la sauvegarde ou le passage du mode Design View au mode Form View prend de 1 a 2 minutes, meme si je n'ai fait aucune modification ?! Les elements de mon application sont sur un reseau Windows 2000. Que faire ? Merci d'avance
Bonjour,
il faudrait aussi enlever dans Outils/options
Suivi des historiques.
ACS INFORMATIQUE
122,rue du Château d'orgemont
49000 ANGERS
Tel: 02 41 68 42 36 Fax: 02 41 68 42 48
----------------------------------------------------------------------------
---------------------
"JJF" <ecla@flv.ch> a écrit dans le message de
news:bha3ln$aru$1@rex.ip-plus.net...
Hello,
Il faut mettre tous les éléments de ton application en local (formulaires,
états, codes, queries, etc..).
Il faut laisser sur le réseau que les tables partagées qui sont ensuite
attachée dans ton application.
C'est ton réseau qui est trop lent.
Ciao
JJ
"Marcis" <marcissartel@voila.fr> a écrit dans le message de news:
0a5101c3609c$578e3cd0$a301280a@phx.gbl...
La lenteur de mon application la rend quasi inutilisable
sans que je sache pourquoi. Il s'agit d'une petite
application avec tables liees d'environ 1Mo et du code VBA
pour les forms et les reports.
Lorsque que je travaille sur une forme pour la modifier,
la sauvegarde ou le passage du mode Design View au mode
Form View prend de 1 a 2 minutes, meme si je n'ai fait
aucune modification ?!
Les elements de mon application sont sur un reseau Windows
2000.
Que faire ?
Merci d'avance
ACS INFORMATIQUE 122,rue du Château d'orgemont 49000 ANGERS Tel: 02 41 68 42 36 Fax: 02 41 68 42 48 ---------------------------------------------------------------------------- --------------------- "JJF" a écrit dans le message de news:bha3ln$aru$
Hello, Il faut mettre tous les éléments de ton application en local (formulaires, états, codes, queries, etc..). Il faut laisser sur le réseau que les tables partagées qui sont ensuite attachée dans ton application. C'est ton réseau qui est trop lent. Ciao JJ "Marcis" a écrit dans le message de news: 0a5101c3609c$578e3cd0$
La lenteur de mon application la rend quasi inutilisable sans que je sache pourquoi. Il s'agit d'une petite application avec tables liees d'environ 1Mo et du code VBA pour les forms et les reports. Lorsque que je travaille sur une forme pour la modifier, la sauvegarde ou le passage du mode Design View au mode Form View prend de 1 a 2 minutes, meme si je n'ai fait aucune modification ?! Les elements de mon application sont sur un reseau Windows 2000. Que faire ? Merci d'avance
Hubert Canevet
Bonjour,
Maintenant que les bonnes réponses ont été données, je peux faire une petite remarque pour le cas où ça ne suffirait pas.
Plus on met des traitements sophistiqués, bien entendu, plus l'exécution sera lente, et ce sera encore plus manifeste si on passe par un réseau, surtout si le réseau est lent.
La solution peut alors passer par des compromis : - voir si les traitements ne peuvent pas être décomposés, pour qu'une partie qui prend du temps soit exécutée moins souvent - vérifier si on a absolument besoin d'un accès partagé en temps réel. En effet, si on copie les deux bases sur le disque dur local on aura non pas forcément un traitement très rapide, mais un délai acceptable. Donc, si chaque enregistrement est attribué à un utilisateur sur la base d'une clef utilisateur, il n'y a pas d'inconvénient majeur à ce que l'utilisateur fasse la mise à jour en local sur sa machine, puis envoie périodiquement, la nuit par exemple, une base de mise à jour, qui contient les enregistrements modifiés. ça suppose que chaque enregistrement contienne un champ DateModification, et que chaque traitement de modification mette à jour ce champ. Attention, ce n'est pas automatique, c'est au programmeur de le faire. Il faut aussi écrire la procédure qui crée la base de transfert et celle qui met à jour la base centrale (j'ai quelque chose là-dessus si ça tente quelqu'un). La base de transfert ne contient que les tables modifiées, et pour celles-ci seulement les enregistrements modifiés (et les nouveaux bien entendu).
Si on a des traitements de contrôle type usine à gaz lors de la saisie, et que les données font l'objet d'une consolidation mensuelle, la transmission par base de transfert risque d'être bien suffisante, et de ne nécessiter la connexion que pendant une minute ou deux à chaque transfert. Bien entendu, il ne faut pas oublier de transférer les données.
Je ne dis pas qu'on passe à ce modèle en deux heures ...
-----Message d'origine----- Bonjour,
il faudrait aussi enlever dans Outils/options Suivi des historiques.
--------------------- "JJF" a écrit dans le message de news:bha3ln$aru$
Hello, Il faut mettre tous les éléments de ton application en local (formulaires,
états, codes, queries, etc..). Il faut laisser sur le réseau que les tables partagées qui sont ensuite
attachée dans ton application. C'est ton réseau qui est trop lent. Ciao JJ "Marcis" a écrit dans le message de news:
0a5101c3609c$578e3cd0$
La lenteur de mon application la rend quasi inutilisable
sans que je sache pourquoi. Il s'agit d'une petite application avec tables liees d'environ 1Mo et du code VBA
pour les forms et les reports. Lorsque que je travaille sur une forme pour la modifier,
la sauvegarde ou le passage du mode Design View au mode
Form View prend de 1 a 2 minutes, meme si je n'ai fait aucune modification ?! Les elements de mon application sont sur un reseau Windows
2000. Que faire ? Merci d'avance
.
Bonjour,
Maintenant que les bonnes réponses ont été données, je
peux faire une petite remarque pour le cas où ça ne
suffirait pas.
Plus on met des traitements sophistiqués, bien entendu,
plus l'exécution sera lente, et ce sera encore plus
manifeste si on passe par un réseau, surtout si le réseau
est lent.
La solution peut alors passer par des compromis :
- voir si les traitements ne peuvent pas être décomposés,
pour qu'une partie qui prend du temps soit exécutée moins
souvent
- vérifier si on a absolument besoin d'un accès partagé en
temps réel. En effet, si on copie les deux bases sur le
disque dur local on aura non pas forcément un traitement
très rapide, mais un délai acceptable. Donc, si chaque
enregistrement est attribué à un utilisateur sur la base
d'une clef utilisateur, il n'y a pas d'inconvénient majeur
à ce que l'utilisateur fasse la mise à jour en local sur
sa machine, puis envoie périodiquement, la nuit par
exemple, une base de mise à jour, qui contient les
enregistrements modifiés. ça suppose que chaque
enregistrement contienne un champ DateModification, et que
chaque traitement de modification mette à jour ce champ.
Attention, ce n'est pas automatique, c'est au programmeur
de le faire. Il faut aussi écrire la procédure qui crée la
base de transfert et celle qui met à jour la base centrale
(j'ai quelque chose là-dessus si ça tente quelqu'un).
La base de transfert ne contient que les tables modifiées,
et pour celles-ci seulement les enregistrements modifiés
(et les nouveaux bien entendu).
Si on a des traitements de contrôle type usine à gaz lors
de la saisie, et que les données font l'objet d'une
consolidation mensuelle, la transmission par base de
transfert risque d'être bien suffisante, et de ne
nécessiter la connexion que pendant une minute ou deux à
chaque transfert. Bien entendu, il ne faut pas oublier de
transférer les données.
Je ne dis pas qu'on passe à ce modèle en deux heures ...
-----Message d'origine-----
Bonjour,
il faudrait aussi enlever dans Outils/options
Suivi des historiques.
Maintenant que les bonnes réponses ont été données, je peux faire une petite remarque pour le cas où ça ne suffirait pas.
Plus on met des traitements sophistiqués, bien entendu, plus l'exécution sera lente, et ce sera encore plus manifeste si on passe par un réseau, surtout si le réseau est lent.
La solution peut alors passer par des compromis : - voir si les traitements ne peuvent pas être décomposés, pour qu'une partie qui prend du temps soit exécutée moins souvent - vérifier si on a absolument besoin d'un accès partagé en temps réel. En effet, si on copie les deux bases sur le disque dur local on aura non pas forcément un traitement très rapide, mais un délai acceptable. Donc, si chaque enregistrement est attribué à un utilisateur sur la base d'une clef utilisateur, il n'y a pas d'inconvénient majeur à ce que l'utilisateur fasse la mise à jour en local sur sa machine, puis envoie périodiquement, la nuit par exemple, une base de mise à jour, qui contient les enregistrements modifiés. ça suppose que chaque enregistrement contienne un champ DateModification, et que chaque traitement de modification mette à jour ce champ. Attention, ce n'est pas automatique, c'est au programmeur de le faire. Il faut aussi écrire la procédure qui crée la base de transfert et celle qui met à jour la base centrale (j'ai quelque chose là-dessus si ça tente quelqu'un). La base de transfert ne contient que les tables modifiées, et pour celles-ci seulement les enregistrements modifiés (et les nouveaux bien entendu).
Si on a des traitements de contrôle type usine à gaz lors de la saisie, et que les données font l'objet d'une consolidation mensuelle, la transmission par base de transfert risque d'être bien suffisante, et de ne nécessiter la connexion que pendant une minute ou deux à chaque transfert. Bien entendu, il ne faut pas oublier de transférer les données.
Je ne dis pas qu'on passe à ce modèle en deux heures ...
-----Message d'origine----- Bonjour,
il faudrait aussi enlever dans Outils/options Suivi des historiques.
--------------------- "JJF" a écrit dans le message de news:bha3ln$aru$
Hello, Il faut mettre tous les éléments de ton application en local (formulaires,
états, codes, queries, etc..). Il faut laisser sur le réseau que les tables partagées qui sont ensuite
attachée dans ton application. C'est ton réseau qui est trop lent. Ciao JJ "Marcis" a écrit dans le message de news:
0a5101c3609c$578e3cd0$
La lenteur de mon application la rend quasi inutilisable
sans que je sache pourquoi. Il s'agit d'une petite application avec tables liees d'environ 1Mo et du code VBA
pour les forms et les reports. Lorsque que je travaille sur une forme pour la modifier,
la sauvegarde ou le passage du mode Design View au mode
Form View prend de 1 a 2 minutes, meme si je n'ai fait aucune modification ?! Les elements de mon application sont sur un reseau Windows
2000. Que faire ? Merci d'avance
.
h.canevet
Ah oui, il existe aussi le système des réplicas. Ce qui m'a fait peur au départ est de savoir qu'on ne peut pas sauvegarder le fichier d'une base répliquée. Cela étant on peut faire un réplica supplémentaire qui sert de sauvegarde. Il faut prendre le temps de tester cette affaire, il est vrai que ça ne serait pas forcément plus long que de monter une usine à gaz. __________________________________________________________________________ "Hubert Canevet" wrote in message news:<045e01c360b2$e4c92ae0$...
Bonjour,
Maintenant que les bonnes r ponses ont t donn es, je peux faire une petite remarque pour le cas o a ne suffirait pas.
Plus on met des traitements sophistiqu s, bien entendu, plus l'ex cution sera lente, et ce sera encore plus manifeste si on passe par un r seau, surtout si le r seau est lent.
La solution peut alors passer par des compromis : - voir si les traitements ne peuvent pas tre d compos s, pour qu'une partie qui prend du temps soit ex cut e moins souvent - v rifier si on a absolument besoin d'un acc s partag en temps r el. En effet, si on copie les deux bases sur le disque dur local on aura non pas forc ment un traitement tr s rapide, mais un d lai acceptable. Donc, si chaque enregistrement est attribu un utilisateur sur la base d'une clef utilisateur, il n'y a pas d'inconv nient majeur ce que l'utilisateur fasse la mise jour en local sur sa machine, puis envoie p riodiquement, la nuit par exemple, une base de mise jour, qui contient les enregistrements modifi s. a suppose que chaque enregistrement contienne un champ DateModification, et que chaque traitement de modification mette jour ce champ. Attention, ce n'est pas automatique, c'est au programmeur de le faire. Il faut aussi crire la proc dure qui cr e la base de transfert et celle qui met jour la base centrale (j'ai quelque chose l -dessus si a tente quelqu'un). La base de transfert ne contient que les tables modifi es, et pour celles-ci seulement les enregistrements modifi s (et les nouveaux bien entendu).
Si on a des traitements de contr le type usine gaz lors de la saisie, et que les donn es font l'objet d'une consolidation mensuelle, la transmission par base de transfert risque d' tre bien suffisante, et de ne n cessiter la connexion que pendant une minute ou deux chaque transfert. Bien entendu, il ne faut pas oublier de transf rer les donn es.
Je ne dis pas qu'on passe ce mod le en deux heures ...
Ah oui, il existe aussi le système des réplicas.
Ce qui m'a fait peur au départ est de savoir qu'on ne peut pas
sauvegarder le fichier d'une base répliquée. Cela étant on peut faire
un réplica supplémentaire qui sert de sauvegarde.
Il faut prendre le temps de tester cette affaire, il est vrai que ça
ne serait pas forcément plus long que de monter une usine à gaz.
__________________________________________________________________________
"Hubert Canevet" <h.canevet@filnet.fr> wrote in message news:<045e01c360b2$e4c92ae0$a001280a@phx.gbl>...
Bonjour,
Maintenant que les bonnes r ponses ont t donn es, je
peux faire une petite remarque pour le cas o a ne
suffirait pas.
Plus on met des traitements sophistiqu s, bien entendu,
plus l'ex cution sera lente, et ce sera encore plus
manifeste si on passe par un r seau, surtout si le r seau
est lent.
La solution peut alors passer par des compromis :
- voir si les traitements ne peuvent pas tre d compos s,
pour qu'une partie qui prend du temps soit ex cut e moins
souvent
- v rifier si on a absolument besoin d'un acc s partag en
temps r el. En effet, si on copie les deux bases sur le
disque dur local on aura non pas forc ment un traitement
tr s rapide, mais un d lai acceptable. Donc, si chaque
enregistrement est attribu un utilisateur sur la base
d'une clef utilisateur, il n'y a pas d'inconv nient majeur
ce que l'utilisateur fasse la mise jour en local sur
sa machine, puis envoie p riodiquement, la nuit par
exemple, une base de mise jour, qui contient les
enregistrements modifi s. a suppose que chaque
enregistrement contienne un champ DateModification, et que
chaque traitement de modification mette jour ce champ.
Attention, ce n'est pas automatique, c'est au programmeur
de le faire. Il faut aussi crire la proc dure qui cr e la
base de transfert et celle qui met jour la base centrale
(j'ai quelque chose l -dessus si a tente quelqu'un).
La base de transfert ne contient que les tables modifi es,
et pour celles-ci seulement les enregistrements modifi s
(et les nouveaux bien entendu).
Si on a des traitements de contr le type usine gaz lors
de la saisie, et que les donn es font l'objet d'une
consolidation mensuelle, la transmission par base de
transfert risque d' tre bien suffisante, et de ne
n cessiter la connexion que pendant une minute ou deux
chaque transfert. Bien entendu, il ne faut pas oublier de
transf rer les donn es.
Je ne dis pas qu'on passe ce mod le en deux heures ...
Ah oui, il existe aussi le système des réplicas. Ce qui m'a fait peur au départ est de savoir qu'on ne peut pas sauvegarder le fichier d'une base répliquée. Cela étant on peut faire un réplica supplémentaire qui sert de sauvegarde. Il faut prendre le temps de tester cette affaire, il est vrai que ça ne serait pas forcément plus long que de monter une usine à gaz. __________________________________________________________________________ "Hubert Canevet" wrote in message news:<045e01c360b2$e4c92ae0$...
Bonjour,
Maintenant que les bonnes r ponses ont t donn es, je peux faire une petite remarque pour le cas o a ne suffirait pas.
Plus on met des traitements sophistiqu s, bien entendu, plus l'ex cution sera lente, et ce sera encore plus manifeste si on passe par un r seau, surtout si le r seau est lent.
La solution peut alors passer par des compromis : - voir si les traitements ne peuvent pas tre d compos s, pour qu'une partie qui prend du temps soit ex cut e moins souvent - v rifier si on a absolument besoin d'un acc s partag en temps r el. En effet, si on copie les deux bases sur le disque dur local on aura non pas forc ment un traitement tr s rapide, mais un d lai acceptable. Donc, si chaque enregistrement est attribu un utilisateur sur la base d'une clef utilisateur, il n'y a pas d'inconv nient majeur ce que l'utilisateur fasse la mise jour en local sur sa machine, puis envoie p riodiquement, la nuit par exemple, une base de mise jour, qui contient les enregistrements modifi s. a suppose que chaque enregistrement contienne un champ DateModification, et que chaque traitement de modification mette jour ce champ. Attention, ce n'est pas automatique, c'est au programmeur de le faire. Il faut aussi crire la proc dure qui cr e la base de transfert et celle qui met jour la base centrale (j'ai quelque chose l -dessus si a tente quelqu'un). La base de transfert ne contient que les tables modifi es, et pour celles-ci seulement les enregistrements modifi s (et les nouveaux bien entendu).
Si on a des traitements de contr le type usine gaz lors de la saisie, et que les donn es font l'objet d'une consolidation mensuelle, la transmission par base de transfert risque d' tre bien suffisante, et de ne n cessiter la connexion que pendant une minute ou deux chaque transfert. Bien entendu, il ne faut pas oublier de transf rer les donn es.
Je ne dis pas qu'on passe ce mod le en deux heures ...
