Bonjour,
J'ai de gros problèmes de performance dans Access 2002 (Office XP avec SP3)
en environnement TSE (Terminal Services) sous Windows Server 2003 SP1:
Les utilisateurs travaillent sur des tables d'environ 50 000 enregistrements
et font des filtres , des tris, des remplacements de valeurs dans les champs.
Au bout de quelques manipulations sur une même table, les performances se
dégradent fortement et il ne faut pas moins de 3 à 4 minutes pour trier une
table de 38 000 enregistrements (en temps normal la même opération prend
moins de 1 seconde).
Ce qu'il y a de suprenant c'est que coté système, il n'y a presque pas de
charge CPU (utilisation à 3 ou 4 % au maximum) et pas d'entrées/sorties
disques non plus. A priori, il ne s'agit donc pas d'un problème de
dimmentionnement de la machine.
Après un compactage de la base tout rentre dans l'ordre ... mais cela ne
dure pas très longtemps : dès que l'on recommence à manipuler la base, les
performances chuttent rapidement !
Les même opérations effectuées avec la même base sur un PC personnel ne
posent aucun problème de ce genre.
Je suis preneur de toute information ou piste de recherche.
Merci pour votre aide.
Bonjour,
J'ai de gros problèmes de performance dans Access 2002 (Office XP avec SP3)
en environnement TSE (Terminal Services) sous Windows Server 2003 SP1:
Les utilisateurs travaillent sur des tables d'environ 50 000 enregistrements
et font des filtres , des tris, des remplacements de valeurs dans les champs.
Au bout de quelques manipulations sur une même table, les performances se
dégradent fortement et il ne faut pas moins de 3 à 4 minutes pour trier une
table de 38 000 enregistrements (en temps normal la même opération prend
moins de 1 seconde).
Ce qu'il y a de suprenant c'est que coté système, il n'y a presque pas de
charge CPU (utilisation à 3 ou 4 % au maximum) et pas d'entrées/sorties
disques non plus. A priori, il ne s'agit donc pas d'un problème de
dimmentionnement de la machine.
Après un compactage de la base tout rentre dans l'ordre ... mais cela ne
dure pas très longtemps : dès que l'on recommence à manipuler la base, les
performances chuttent rapidement !
Les même opérations effectuées avec la même base sur un PC personnel ne
posent aucun problème de ce genre.
Je suis preneur de toute information ou piste de recherche.
Merci pour votre aide.
Bonjour,
J'ai de gros problèmes de performance dans Access 2002 (Office XP avec SP3)
en environnement TSE (Terminal Services) sous Windows Server 2003 SP1:
Les utilisateurs travaillent sur des tables d'environ 50 000 enregistrements
et font des filtres , des tris, des remplacements de valeurs dans les champs.
Au bout de quelques manipulations sur une même table, les performances se
dégradent fortement et il ne faut pas moins de 3 à 4 minutes pour trier une
table de 38 000 enregistrements (en temps normal la même opération prend
moins de 1 seconde).
Ce qu'il y a de suprenant c'est que coté système, il n'y a presque pas de
charge CPU (utilisation à 3 ou 4 % au maximum) et pas d'entrées/sorties
disques non plus. A priori, il ne s'agit donc pas d'un problème de
dimmentionnement de la machine.
Après un compactage de la base tout rentre dans l'ordre ... mais cela ne
dure pas très longtemps : dès que l'on recommence à manipuler la base, les
performances chuttent rapidement !
Les même opérations effectuées avec la même base sur un PC personnel ne
posent aucun problème de ce genre.
Je suis preneur de toute information ou piste de recherche.
Merci pour votre aide.
Bonjour,
Il se pourrait que le nombre d'utilisateurs simultanés joue sur les
performances.
Par ailleurs, est-ce que la base utilise des tables liées?Bonjour,
J'ai de gros problèmes de performance dans Access 2002 (Office XP avec SP3)
en environnement TSE (Terminal Services) sous Windows Server 2003 SP1:
Les utilisateurs travaillent sur des tables d'environ 50 000 enregistrements
et font des filtres , des tris, des remplacements de valeurs dans les champs.
Au bout de quelques manipulations sur une même table, les performances se
dégradent fortement et il ne faut pas moins de 3 à 4 minutes pour trier une
table de 38 000 enregistrements (en temps normal la même opération prend
moins de 1 seconde).
Ce qu'il y a de suprenant c'est que coté système, il n'y a presque pas de
charge CPU (utilisation à 3 ou 4 % au maximum) et pas d'entrées/sorties
disques non plus. A priori, il ne s'agit donc pas d'un problème de
dimmentionnement de la machine.
Après un compactage de la base tout rentre dans l'ordre ... mais cela ne
dure pas très longtemps : dès que l'on recommence à manipuler la base, les
performances chuttent rapidement !
Les même opérations effectuées avec la même base sur un PC personnel ne
posent aucun problème de ce genre.
Je suis preneur de toute information ou piste de recherche.
Merci pour votre aide.
Bonjour,
Il se pourrait que le nombre d'utilisateurs simultanés joue sur les
performances.
Par ailleurs, est-ce que la base utilise des tables liées?
Bonjour,
J'ai de gros problèmes de performance dans Access 2002 (Office XP avec SP3)
en environnement TSE (Terminal Services) sous Windows Server 2003 SP1:
Les utilisateurs travaillent sur des tables d'environ 50 000 enregistrements
et font des filtres , des tris, des remplacements de valeurs dans les champs.
Au bout de quelques manipulations sur une même table, les performances se
dégradent fortement et il ne faut pas moins de 3 à 4 minutes pour trier une
table de 38 000 enregistrements (en temps normal la même opération prend
moins de 1 seconde).
Ce qu'il y a de suprenant c'est que coté système, il n'y a presque pas de
charge CPU (utilisation à 3 ou 4 % au maximum) et pas d'entrées/sorties
disques non plus. A priori, il ne s'agit donc pas d'un problème de
dimmentionnement de la machine.
Après un compactage de la base tout rentre dans l'ordre ... mais cela ne
dure pas très longtemps : dès que l'on recommence à manipuler la base, les
performances chuttent rapidement !
Les même opérations effectuées avec la même base sur un PC personnel ne
posent aucun problème de ce genre.
Je suis preneur de toute information ou piste de recherche.
Merci pour votre aide.
Bonjour,
Il se pourrait que le nombre d'utilisateurs simultanés joue sur les
performances.
Par ailleurs, est-ce que la base utilise des tables liées?Bonjour,
J'ai de gros problèmes de performance dans Access 2002 (Office XP avec SP3)
en environnement TSE (Terminal Services) sous Windows Server 2003 SP1:
Les utilisateurs travaillent sur des tables d'environ 50 000 enregistrements
et font des filtres , des tris, des remplacements de valeurs dans les champs.
Au bout de quelques manipulations sur une même table, les performances se
dégradent fortement et il ne faut pas moins de 3 à 4 minutes pour trier une
table de 38 000 enregistrements (en temps normal la même opération prend
moins de 1 seconde).
Ce qu'il y a de suprenant c'est que coté système, il n'y a presque pas de
charge CPU (utilisation à 3 ou 4 % au maximum) et pas d'entrées/sorties
disques non plus. A priori, il ne s'agit donc pas d'un problème de
dimmentionnement de la machine.
Après un compactage de la base tout rentre dans l'ordre ... mais cela ne
dure pas très longtemps : dès que l'on recommence à manipuler la base, les
performances chuttent rapidement !
Les même opérations effectuées avec la même base sur un PC personnel ne
posent aucun problème de ce genre.
Je suis preneur de toute information ou piste de recherche.
Merci pour votre aide.
Le nombre d'utilisateurs simultanés n'est jamais très important : 5 au
maximum et, comme je l'ai dit il n'y pas de soucis ou niveau de la capacité
du serveur (CPU, Mémoire ou disque) . Chaque utilisateur travaille sur sa
propre base Access : il n'y a pas ouverture simultanée de la même base (du
même fichier .mdb) par plusieurs utilisateurs.
Oui, il y a des tables liés dans la base access (liaison vers base SQL
Server) mais ce n'est pas sur ces tables que sont effectuées les opérations
que j'ai décrites. Les tables qui posent problème sont des tables 100%
Access, sans aucune liaison externe ou vers d'autres tables.
Par ailleurs, même si l'on met la table dans une base Access qui ne contient
que cette table, on finit toujours par avoir les même problèmes après
quelques manipulations.
Le nombre d'utilisateurs simultanés n'est jamais très important : 5 au
maximum et, comme je l'ai dit il n'y pas de soucis ou niveau de la capacité
du serveur (CPU, Mémoire ou disque) . Chaque utilisateur travaille sur sa
propre base Access : il n'y a pas ouverture simultanée de la même base (du
même fichier .mdb) par plusieurs utilisateurs.
Oui, il y a des tables liés dans la base access (liaison vers base SQL
Server) mais ce n'est pas sur ces tables que sont effectuées les opérations
que j'ai décrites. Les tables qui posent problème sont des tables 100%
Access, sans aucune liaison externe ou vers d'autres tables.
Par ailleurs, même si l'on met la table dans une base Access qui ne contient
que cette table, on finit toujours par avoir les même problèmes après
quelques manipulations.
Le nombre d'utilisateurs simultanés n'est jamais très important : 5 au
maximum et, comme je l'ai dit il n'y pas de soucis ou niveau de la capacité
du serveur (CPU, Mémoire ou disque) . Chaque utilisateur travaille sur sa
propre base Access : il n'y a pas ouverture simultanée de la même base (du
même fichier .mdb) par plusieurs utilisateurs.
Oui, il y a des tables liés dans la base access (liaison vers base SQL
Server) mais ce n'est pas sur ces tables que sont effectuées les opérations
que j'ai décrites. Les tables qui posent problème sont des tables 100%
Access, sans aucune liaison externe ou vers d'autres tables.
Par ailleurs, même si l'on met la table dans une base Access qui ne contient
que cette table, on finit toujours par avoir les même problèmes après
quelques manipulations.
Apparemment donc, il n'y a qu'un seul utilisateur simultané.
Je ne vois pas trop...
Pour optimiser le tri, il vaut mieux indexer les champs concernés, mais
c'est normalement indépendant du système (TSE ou local)...Le nombre d'utilisateurs simultanés n'est jamais très important : 5 au
maximum et, comme je l'ai dit il n'y pas de soucis ou niveau de la capacité
du serveur (CPU, Mémoire ou disque) . Chaque utilisateur travaille sur sa
propre base Access : il n'y a pas ouverture simultanée de la même base (du
même fichier .mdb) par plusieurs utilisateurs.
Oui, il y a des tables liés dans la base access (liaison vers base SQL
Server) mais ce n'est pas sur ces tables que sont effectuées les opérations
que j'ai décrites. Les tables qui posent problème sont des tables 100%
Access, sans aucune liaison externe ou vers d'autres tables.
Par ailleurs, même si l'on met la table dans une base Access qui ne contient
que cette table, on finit toujours par avoir les même problèmes après
quelques manipulations.
Apparemment donc, il n'y a qu'un seul utilisateur simultané.
Je ne vois pas trop...
Pour optimiser le tri, il vaut mieux indexer les champs concernés, mais
c'est normalement indépendant du système (TSE ou local)...
Le nombre d'utilisateurs simultanés n'est jamais très important : 5 au
maximum et, comme je l'ai dit il n'y pas de soucis ou niveau de la capacité
du serveur (CPU, Mémoire ou disque) . Chaque utilisateur travaille sur sa
propre base Access : il n'y a pas ouverture simultanée de la même base (du
même fichier .mdb) par plusieurs utilisateurs.
Oui, il y a des tables liés dans la base access (liaison vers base SQL
Server) mais ce n'est pas sur ces tables que sont effectuées les opérations
que j'ai décrites. Les tables qui posent problème sont des tables 100%
Access, sans aucune liaison externe ou vers d'autres tables.
Par ailleurs, même si l'on met la table dans une base Access qui ne contient
que cette table, on finit toujours par avoir les même problèmes après
quelques manipulations.
Apparemment donc, il n'y a qu'un seul utilisateur simultané.
Je ne vois pas trop...
Pour optimiser le tri, il vaut mieux indexer les champs concernés, mais
c'est normalement indépendant du système (TSE ou local)...Le nombre d'utilisateurs simultanés n'est jamais très important : 5 au
maximum et, comme je l'ai dit il n'y pas de soucis ou niveau de la capacité
du serveur (CPU, Mémoire ou disque) . Chaque utilisateur travaille sur sa
propre base Access : il n'y a pas ouverture simultanée de la même base (du
même fichier .mdb) par plusieurs utilisateurs.
Oui, il y a des tables liés dans la base access (liaison vers base SQL
Server) mais ce n'est pas sur ces tables que sont effectuées les opérations
que j'ai décrites. Les tables qui posent problème sont des tables 100%
Access, sans aucune liaison externe ou vers d'autres tables.
Par ailleurs, même si l'on met la table dans une base Access qui ne contient
que cette table, on finit toujours par avoir les même problèmes après
quelques manipulations.
Il y a jusqu'à 5 utilisateurs simultanés sur le serveur mais chaque
utilisateur utilise sa propre base Access. Une base Access (un fichier mdb)
n'est jamais ouvert simultanément par plusieurs utilisateurs.
Je ne suis pas sûr que le problème vienne de TSE, j'ai juste indiqué ce
point pour indiquer le contexte global d'exécution.
En faisant quelques tests complémentaire, il s'avère que les performances se
dégradent particulièrement après avoir effectué de grosses mises à jour dans
la base. Du style : remplacement d'un champ de la valeur1 pour la valeur2 sur
20 000 enregistrements.
Par ailleurs lors de ces mises à jour on arrive rarement à mettre plus de
9100 (environ) enregistrements simultanément. On obtient le message d'erreur
"Impossible de remplacer la valeur du champ" , "Corrigez les erreurs
éventuelles avant d'effectuer d'autres remplacements" .
Tout avis m'interesse. Merci...Apparemment donc, il n'y a qu'un seul utilisateur simultané.
Je ne vois pas trop...
Pour optimiser le tri, il vaut mieux indexer les champs concernés, mais
c'est normalement indépendant du système (TSE ou local)...Le nombre d'utilisateurs simultanés n'est jamais très important : 5 au
maximum et, comme je l'ai dit il n'y pas de soucis ou niveau de la capacité
du serveur (CPU, Mémoire ou disque) . Chaque utilisateur travaille sur sa
propre base Access : il n'y a pas ouverture simultanée de la même base (du
même fichier .mdb) par plusieurs utilisateurs.
Oui, il y a des tables liés dans la base access (liaison vers base SQL
Server) mais ce n'est pas sur ces tables que sont effectuées les opérations
que j'ai décrites. Les tables qui posent problème sont des tables 100%
Access, sans aucune liaison externe ou vers d'autres tables.
Par ailleurs, même si l'on met la table dans une base Access qui ne contient
que cette table, on finit toujours par avoir les même problèmes après
quelques manipulations.
Il y a jusqu'à 5 utilisateurs simultanés sur le serveur mais chaque
utilisateur utilise sa propre base Access. Une base Access (un fichier mdb)
n'est jamais ouvert simultanément par plusieurs utilisateurs.
Je ne suis pas sûr que le problème vienne de TSE, j'ai juste indiqué ce
point pour indiquer le contexte global d'exécution.
En faisant quelques tests complémentaire, il s'avère que les performances se
dégradent particulièrement après avoir effectué de grosses mises à jour dans
la base. Du style : remplacement d'un champ de la valeur1 pour la valeur2 sur
20 000 enregistrements.
Par ailleurs lors de ces mises à jour on arrive rarement à mettre plus de
9100 (environ) enregistrements simultanément. On obtient le message d'erreur
"Impossible de remplacer la valeur du champ" , "Corrigez les erreurs
éventuelles avant d'effectuer d'autres remplacements" .
Tout avis m'interesse. Merci...
Apparemment donc, il n'y a qu'un seul utilisateur simultané.
Je ne vois pas trop...
Pour optimiser le tri, il vaut mieux indexer les champs concernés, mais
c'est normalement indépendant du système (TSE ou local)...
Le nombre d'utilisateurs simultanés n'est jamais très important : 5 au
maximum et, comme je l'ai dit il n'y pas de soucis ou niveau de la capacité
du serveur (CPU, Mémoire ou disque) . Chaque utilisateur travaille sur sa
propre base Access : il n'y a pas ouverture simultanée de la même base (du
même fichier .mdb) par plusieurs utilisateurs.
Oui, il y a des tables liés dans la base access (liaison vers base SQL
Server) mais ce n'est pas sur ces tables que sont effectuées les opérations
que j'ai décrites. Les tables qui posent problème sont des tables 100%
Access, sans aucune liaison externe ou vers d'autres tables.
Par ailleurs, même si l'on met la table dans une base Access qui ne contient
que cette table, on finit toujours par avoir les même problèmes après
quelques manipulations.
Il y a jusqu'à 5 utilisateurs simultanés sur le serveur mais chaque
utilisateur utilise sa propre base Access. Une base Access (un fichier mdb)
n'est jamais ouvert simultanément par plusieurs utilisateurs.
Je ne suis pas sûr que le problème vienne de TSE, j'ai juste indiqué ce
point pour indiquer le contexte global d'exécution.
En faisant quelques tests complémentaire, il s'avère que les performances se
dégradent particulièrement après avoir effectué de grosses mises à jour dans
la base. Du style : remplacement d'un champ de la valeur1 pour la valeur2 sur
20 000 enregistrements.
Par ailleurs lors de ces mises à jour on arrive rarement à mettre plus de
9100 (environ) enregistrements simultanément. On obtient le message d'erreur
"Impossible de remplacer la valeur du champ" , "Corrigez les erreurs
éventuelles avant d'effectuer d'autres remplacements" .
Tout avis m'interesse. Merci...Apparemment donc, il n'y a qu'un seul utilisateur simultané.
Je ne vois pas trop...
Pour optimiser le tri, il vaut mieux indexer les champs concernés, mais
c'est normalement indépendant du système (TSE ou local)...Le nombre d'utilisateurs simultanés n'est jamais très important : 5 au
maximum et, comme je l'ai dit il n'y pas de soucis ou niveau de la capacité
du serveur (CPU, Mémoire ou disque) . Chaque utilisateur travaille sur sa
propre base Access : il n'y a pas ouverture simultanée de la même base (du
même fichier .mdb) par plusieurs utilisateurs.
Oui, il y a des tables liés dans la base access (liaison vers base SQL
Server) mais ce n'est pas sur ces tables que sont effectuées les opérations
que j'ai décrites. Les tables qui posent problème sont des tables 100%
Access, sans aucune liaison externe ou vers d'autres tables.
Par ailleurs, même si l'on met la table dans une base Access qui ne contient
que cette table, on finit toujours par avoir les même problèmes après
quelques manipulations.
Je ne vois pas vraiment d'où ça peut venir...
D'autant que j'ai une base avec 39000 enregistrements dans une table, j'ai
mis à jour toute la table une dizaine de fois, pour essayer et ça fonctionne
très bien. Je sui également sous Windows Server 2003 SP1 en TSE avec Access
XP SP2.
Peut-être le disque dur qui encaisse difficilement toutes ces
lectures/écritures, mais ça m'étonne (je ne suis pas expert sur ce point...)
De quelle manière mettez-vous à jour les enregistrements?
Par des requêtes exécution lancées dans Access?
Par du code VBA (DAO, ADO) ?
etc?Il y a jusqu'à 5 utilisateurs simultanés sur le serveur mais chaque
utilisateur utilise sa propre base Access. Une base Access (un fichier mdb)
n'est jamais ouvert simultanément par plusieurs utilisateurs.
Je ne suis pas sûr que le problème vienne de TSE, j'ai juste indiqué ce
point pour indiquer le contexte global d'exécution.
En faisant quelques tests complémentaire, il s'avère que les performances se
dégradent particulièrement après avoir effectué de grosses mises à jour dans
la base. Du style : remplacement d'un champ de la valeur1 pour la valeur2 sur
20 000 enregistrements.
Par ailleurs lors de ces mises à jour on arrive rarement à mettre plus de
9100 (environ) enregistrements simultanément. On obtient le message d'erreur
"Impossible de remplacer la valeur du champ" , "Corrigez les erreurs
éventuelles avant d'effectuer d'autres remplacements" .
Tout avis m'interesse. Merci...Apparemment donc, il n'y a qu'un seul utilisateur simultané.
Je ne vois pas trop...
Pour optimiser le tri, il vaut mieux indexer les champs concernés, mais
c'est normalement indépendant du système (TSE ou local)...Le nombre d'utilisateurs simultanés n'est jamais très important : 5 au
maximum et, comme je l'ai dit il n'y pas de soucis ou niveau de la capacité
du serveur (CPU, Mémoire ou disque) . Chaque utilisateur travaille sur sa
propre base Access : il n'y a pas ouverture simultanée de la même base (du
même fichier .mdb) par plusieurs utilisateurs.
Oui, il y a des tables liés dans la base access (liaison vers base SQL
Server) mais ce n'est pas sur ces tables que sont effectuées les opérations
que j'ai décrites. Les tables qui posent problème sont des tables 100%
Access, sans aucune liaison externe ou vers d'autres tables.
Par ailleurs, même si l'on met la table dans une base Access qui ne contient
que cette table, on finit toujours par avoir les même problèmes après
quelques manipulations.
Je ne vois pas vraiment d'où ça peut venir...
D'autant que j'ai une base avec 39000 enregistrements dans une table, j'ai
mis à jour toute la table une dizaine de fois, pour essayer et ça fonctionne
très bien. Je sui également sous Windows Server 2003 SP1 en TSE avec Access
XP SP2.
Peut-être le disque dur qui encaisse difficilement toutes ces
lectures/écritures, mais ça m'étonne (je ne suis pas expert sur ce point...)
De quelle manière mettez-vous à jour les enregistrements?
Par des requêtes exécution lancées dans Access?
Par du code VBA (DAO, ADO) ?
etc?
Il y a jusqu'à 5 utilisateurs simultanés sur le serveur mais chaque
utilisateur utilise sa propre base Access. Une base Access (un fichier mdb)
n'est jamais ouvert simultanément par plusieurs utilisateurs.
Je ne suis pas sûr que le problème vienne de TSE, j'ai juste indiqué ce
point pour indiquer le contexte global d'exécution.
En faisant quelques tests complémentaire, il s'avère que les performances se
dégradent particulièrement après avoir effectué de grosses mises à jour dans
la base. Du style : remplacement d'un champ de la valeur1 pour la valeur2 sur
20 000 enregistrements.
Par ailleurs lors de ces mises à jour on arrive rarement à mettre plus de
9100 (environ) enregistrements simultanément. On obtient le message d'erreur
"Impossible de remplacer la valeur du champ" , "Corrigez les erreurs
éventuelles avant d'effectuer d'autres remplacements" .
Tout avis m'interesse. Merci...
Apparemment donc, il n'y a qu'un seul utilisateur simultané.
Je ne vois pas trop...
Pour optimiser le tri, il vaut mieux indexer les champs concernés, mais
c'est normalement indépendant du système (TSE ou local)...
Le nombre d'utilisateurs simultanés n'est jamais très important : 5 au
maximum et, comme je l'ai dit il n'y pas de soucis ou niveau de la capacité
du serveur (CPU, Mémoire ou disque) . Chaque utilisateur travaille sur sa
propre base Access : il n'y a pas ouverture simultanée de la même base (du
même fichier .mdb) par plusieurs utilisateurs.
Oui, il y a des tables liés dans la base access (liaison vers base SQL
Server) mais ce n'est pas sur ces tables que sont effectuées les opérations
que j'ai décrites. Les tables qui posent problème sont des tables 100%
Access, sans aucune liaison externe ou vers d'autres tables.
Par ailleurs, même si l'on met la table dans une base Access qui ne contient
que cette table, on finit toujours par avoir les même problèmes après
quelques manipulations.
Je ne vois pas vraiment d'où ça peut venir...
D'autant que j'ai une base avec 39000 enregistrements dans une table, j'ai
mis à jour toute la table une dizaine de fois, pour essayer et ça fonctionne
très bien. Je sui également sous Windows Server 2003 SP1 en TSE avec Access
XP SP2.
Peut-être le disque dur qui encaisse difficilement toutes ces
lectures/écritures, mais ça m'étonne (je ne suis pas expert sur ce point...)
De quelle manière mettez-vous à jour les enregistrements?
Par des requêtes exécution lancées dans Access?
Par du code VBA (DAO, ADO) ?
etc?Il y a jusqu'à 5 utilisateurs simultanés sur le serveur mais chaque
utilisateur utilise sa propre base Access. Une base Access (un fichier mdb)
n'est jamais ouvert simultanément par plusieurs utilisateurs.
Je ne suis pas sûr que le problème vienne de TSE, j'ai juste indiqué ce
point pour indiquer le contexte global d'exécution.
En faisant quelques tests complémentaire, il s'avère que les performances se
dégradent particulièrement après avoir effectué de grosses mises à jour dans
la base. Du style : remplacement d'un champ de la valeur1 pour la valeur2 sur
20 000 enregistrements.
Par ailleurs lors de ces mises à jour on arrive rarement à mettre plus de
9100 (environ) enregistrements simultanément. On obtient le message d'erreur
"Impossible de remplacer la valeur du champ" , "Corrigez les erreurs
éventuelles avant d'effectuer d'autres remplacements" .
Tout avis m'interesse. Merci...Apparemment donc, il n'y a qu'un seul utilisateur simultané.
Je ne vois pas trop...
Pour optimiser le tri, il vaut mieux indexer les champs concernés, mais
c'est normalement indépendant du système (TSE ou local)...Le nombre d'utilisateurs simultanés n'est jamais très important : 5 au
maximum et, comme je l'ai dit il n'y pas de soucis ou niveau de la capacité
du serveur (CPU, Mémoire ou disque) . Chaque utilisateur travaille sur sa
propre base Access : il n'y a pas ouverture simultanée de la même base (du
même fichier .mdb) par plusieurs utilisateurs.
Oui, il y a des tables liés dans la base access (liaison vers base SQL
Server) mais ce n'est pas sur ces tables que sont effectuées les opérations
que j'ai décrites. Les tables qui posent problème sont des tables 100%
Access, sans aucune liaison externe ou vers d'autres tables.
Par ailleurs, même si l'on met la table dans une base Access qui ne contient
que cette table, on finit toujours par avoir les même problèmes après
quelques manipulations.
A priori pas de problème coté disques : il s'agit d'une unité de 5 disques
SCSI à 10 000 tr/min montés en RAID 5.
Les mises à jour sont faites directement dans l'interface d'Access : les
utilisateurs ouvrent la table (double clic), font un filtre sur une colonne,
se positionnent sur une autre colone puis vont dans le menu 'Edition /
Remplacer' (ou CTRL-H) et renseignent les valeurs de recherche et de
remplacement et cliquent sur le bouton 'Remplacer tout'.
A priori pas de problème coté disques : il s'agit d'une unité de 5 disques
SCSI à 10 000 tr/min montés en RAID 5.
Les mises à jour sont faites directement dans l'interface d'Access : les
utilisateurs ouvrent la table (double clic), font un filtre sur une colonne,
se positionnent sur une autre colone puis vont dans le menu 'Edition /
Remplacer' (ou CTRL-H) et renseignent les valeurs de recherche et de
remplacement et cliquent sur le bouton 'Remplacer tout'.
A priori pas de problème coté disques : il s'agit d'une unité de 5 disques
SCSI à 10 000 tr/min montés en RAID 5.
Les mises à jour sont faites directement dans l'interface d'Access : les
utilisateurs ouvrent la table (double clic), font un filtre sur une colonne,
se positionnent sur une autre colone puis vont dans le menu 'Edition /
Remplacer' (ou CTRL-H) et renseignent les valeurs de recherche et de
remplacement et cliquent sur le bouton 'Remplacer tout'.
Dans ce cas je ne suis guère étonné qu'il y ait des problèmes de
performances...
Mon processeur tourne à 100% lorsque je fais l'opération.
Faire un Rechercher/Remplacer dans une table de 50000 enregistrements relève
du défi à mon avis.
En outre, Il est fort possible que les performances soient altérées en TSE
du fait du rafraîchissement de la barre d'état et des valeurs remplacées.
Ne pouvez-vous pas plutôt opter pour une solution de requête mise à jour, ne
serait-ce qu'une requête paramétrée avec comme paramètres "TexteCherché" et
"TexteRemplacement", par exemple?A priori pas de problème coté disques : il s'agit d'une unité de 5 disques
SCSI à 10 000 tr/min montés en RAID 5.
Les mises à jour sont faites directement dans l'interface d'Access : les
utilisateurs ouvrent la table (double clic), font un filtre sur une colonne,
se positionnent sur une autre colone puis vont dans le menu 'Edition /
Remplacer' (ou CTRL-H) et renseignent les valeurs de recherche et de
remplacement et cliquent sur le bouton 'Remplacer tout'.
Dans ce cas je ne suis guère étonné qu'il y ait des problèmes de
performances...
Mon processeur tourne à 100% lorsque je fais l'opération.
Faire un Rechercher/Remplacer dans une table de 50000 enregistrements relève
du défi à mon avis.
En outre, Il est fort possible que les performances soient altérées en TSE
du fait du rafraîchissement de la barre d'état et des valeurs remplacées.
Ne pouvez-vous pas plutôt opter pour une solution de requête mise à jour, ne
serait-ce qu'une requête paramétrée avec comme paramètres "TexteCherché" et
"TexteRemplacement", par exemple?
A priori pas de problème coté disques : il s'agit d'une unité de 5 disques
SCSI à 10 000 tr/min montés en RAID 5.
Les mises à jour sont faites directement dans l'interface d'Access : les
utilisateurs ouvrent la table (double clic), font un filtre sur une colonne,
se positionnent sur une autre colone puis vont dans le menu 'Edition /
Remplacer' (ou CTRL-H) et renseignent les valeurs de recherche et de
remplacement et cliquent sur le bouton 'Remplacer tout'.
Dans ce cas je ne suis guère étonné qu'il y ait des problèmes de
performances...
Mon processeur tourne à 100% lorsque je fais l'opération.
Faire un Rechercher/Remplacer dans une table de 50000 enregistrements relève
du défi à mon avis.
En outre, Il est fort possible que les performances soient altérées en TSE
du fait du rafraîchissement de la barre d'état et des valeurs remplacées.
Ne pouvez-vous pas plutôt opter pour une solution de requête mise à jour, ne
serait-ce qu'une requête paramétrée avec comme paramètres "TexteCherché" et
"TexteRemplacement", par exemple?A priori pas de problème coté disques : il s'agit d'une unité de 5 disques
SCSI à 10 000 tr/min montés en RAID 5.
Les mises à jour sont faites directement dans l'interface d'Access : les
utilisateurs ouvrent la table (double clic), font un filtre sur une colonne,
se positionnent sur une autre colone puis vont dans le menu 'Edition /
Remplacer' (ou CTRL-H) et renseignent les valeurs de recherche et de
remplacement et cliquent sur le bouton 'Remplacer tout'.
Alors dans ce cas pourquoi pas créer un formulaire rechercher/Remplacer.
Cela nécessite 3 opérations :
1. Créer un bouton de barre d'outil personnalisé "Rechercher/Remplacer"
2. Créer un fonction MonRechercherRemplacer() dans un module standard, qui
sera appelée par le bouton
3. Créer un Formulaire "FSearchReplace" de recherche/remplacement qui sera
affiché par cette procédure
Procédure 2 :
----------------
La fonction doit être comme suit :
Public Function MonRechercherRemplacer()
Const FRM_CHERCHE_REPLACE As String = "FSearchReplace"
Dim frm As Access.Form
Dim acObject As Access.AccessObject
Dim sObjName As String
Dim sTable As String
' Vérifie que l'objet en cours est une table
' Dans ce cas, vérifie que la table est ouverte en mode feuille de données
' et non en mode création, par exemple
sObjName = CurrentObjectName
Select Case CurrentObjectType
Case acTable
Set acObject = CurrentData.AllTables(sObjName)
If acObject.IsLoaded Then
If acObject.CurrentView = acCurViewDatasheet Then
sTable = sObjName
End If
End If
End Select
' Si l'Obet actif est bien une Table ouverte en mode feuille de données,
' Affiche le formulaire
' If Len(sTable) Then '(Test pas indispensable)
DoCmd.OpenForm FRM_CHERCHE_REPLACE, acNormal
Set frm = Forms(FRM_CHERCHE_REPLACE)
frm.ShowReplace sTable
' End If
End Function
Procédure 1 bis :
-------------------
Mettre la propriété "sur action" du bouton à :
=MonRechercherRemplacer()
Procédure 3 :
-----------------
Placer la Procédure suivante dans le Formulaire :
Public Sub ShowReplace(ByVal sTable As String)
Me.Caption = "Rechercher/Remplacer : " & sTable
cmbFields.RowSource = sTable
End Sub
Le formulaire comporte une zone de liste déroulante cmbFields dont le type
de source ("Origine Source") est "Liste des champs".
Afin d'optimiser l'interface, le formulaire devra également avoir la
propriété "fenêtre indépendante" à "oui" pour s'afficher au-dessus de la
table.
Reste l'Etape 4 : Mettre en place le code SQL et son exécution pour
effectuer le remplacement à partir du champ sélectionné par l'utilisateur, le
texte cherché et le texte de remplacement indiqués dans le formulaire.
A noter enfin que l'idéal aurait été de fermer le formulaire de recherche
lorsque la table est fermée, mais je n'ai pas trouvé comment pour le moment
(même en ayant recours au formulaire renvoyé par Screen.ActiveDatasheet).
A noter également : Si la fenêtre active est la fenêtre Base de données,
l'objet courant et chargé peut être la table sélectionnée dans la liste des
tables même si en réalité elle n'est pas la fenêtre active).
En espérant que cela t'inspirera... (ca peut paraitre complexe, mais en
réalité c'est très simple).
Alors dans ce cas pourquoi pas créer un formulaire rechercher/Remplacer.
Cela nécessite 3 opérations :
1. Créer un bouton de barre d'outil personnalisé "Rechercher/Remplacer"
2. Créer un fonction MonRechercherRemplacer() dans un module standard, qui
sera appelée par le bouton
3. Créer un Formulaire "FSearchReplace" de recherche/remplacement qui sera
affiché par cette procédure
Procédure 2 :
----------------
La fonction doit être comme suit :
Public Function MonRechercherRemplacer()
Const FRM_CHERCHE_REPLACE As String = "FSearchReplace"
Dim frm As Access.Form
Dim acObject As Access.AccessObject
Dim sObjName As String
Dim sTable As String
' Vérifie que l'objet en cours est une table
' Dans ce cas, vérifie que la table est ouverte en mode feuille de données
' et non en mode création, par exemple
sObjName = CurrentObjectName
Select Case CurrentObjectType
Case acTable
Set acObject = CurrentData.AllTables(sObjName)
If acObject.IsLoaded Then
If acObject.CurrentView = acCurViewDatasheet Then
sTable = sObjName
End If
End If
End Select
' Si l'Obet actif est bien une Table ouverte en mode feuille de données,
' Affiche le formulaire
' If Len(sTable) Then '(Test pas indispensable)
DoCmd.OpenForm FRM_CHERCHE_REPLACE, acNormal
Set frm = Forms(FRM_CHERCHE_REPLACE)
frm.ShowReplace sTable
' End If
End Function
Procédure 1 bis :
-------------------
Mettre la propriété "sur action" du bouton à :
=MonRechercherRemplacer()
Procédure 3 :
-----------------
Placer la Procédure suivante dans le Formulaire :
Public Sub ShowReplace(ByVal sTable As String)
Me.Caption = "Rechercher/Remplacer : " & sTable
cmbFields.RowSource = sTable
End Sub
Le formulaire comporte une zone de liste déroulante cmbFields dont le type
de source ("Origine Source") est "Liste des champs".
Afin d'optimiser l'interface, le formulaire devra également avoir la
propriété "fenêtre indépendante" à "oui" pour s'afficher au-dessus de la
table.
Reste l'Etape 4 : Mettre en place le code SQL et son exécution pour
effectuer le remplacement à partir du champ sélectionné par l'utilisateur, le
texte cherché et le texte de remplacement indiqués dans le formulaire.
A noter enfin que l'idéal aurait été de fermer le formulaire de recherche
lorsque la table est fermée, mais je n'ai pas trouvé comment pour le moment
(même en ayant recours au formulaire renvoyé par Screen.ActiveDatasheet).
A noter également : Si la fenêtre active est la fenêtre Base de données,
l'objet courant et chargé peut être la table sélectionnée dans la liste des
tables même si en réalité elle n'est pas la fenêtre active).
En espérant que cela t'inspirera... (ca peut paraitre complexe, mais en
réalité c'est très simple).
Alors dans ce cas pourquoi pas créer un formulaire rechercher/Remplacer.
Cela nécessite 3 opérations :
1. Créer un bouton de barre d'outil personnalisé "Rechercher/Remplacer"
2. Créer un fonction MonRechercherRemplacer() dans un module standard, qui
sera appelée par le bouton
3. Créer un Formulaire "FSearchReplace" de recherche/remplacement qui sera
affiché par cette procédure
Procédure 2 :
----------------
La fonction doit être comme suit :
Public Function MonRechercherRemplacer()
Const FRM_CHERCHE_REPLACE As String = "FSearchReplace"
Dim frm As Access.Form
Dim acObject As Access.AccessObject
Dim sObjName As String
Dim sTable As String
' Vérifie que l'objet en cours est une table
' Dans ce cas, vérifie que la table est ouverte en mode feuille de données
' et non en mode création, par exemple
sObjName = CurrentObjectName
Select Case CurrentObjectType
Case acTable
Set acObject = CurrentData.AllTables(sObjName)
If acObject.IsLoaded Then
If acObject.CurrentView = acCurViewDatasheet Then
sTable = sObjName
End If
End If
End Select
' Si l'Obet actif est bien une Table ouverte en mode feuille de données,
' Affiche le formulaire
' If Len(sTable) Then '(Test pas indispensable)
DoCmd.OpenForm FRM_CHERCHE_REPLACE, acNormal
Set frm = Forms(FRM_CHERCHE_REPLACE)
frm.ShowReplace sTable
' End If
End Function
Procédure 1 bis :
-------------------
Mettre la propriété "sur action" du bouton à :
=MonRechercherRemplacer()
Procédure 3 :
-----------------
Placer la Procédure suivante dans le Formulaire :
Public Sub ShowReplace(ByVal sTable As String)
Me.Caption = "Rechercher/Remplacer : " & sTable
cmbFields.RowSource = sTable
End Sub
Le formulaire comporte une zone de liste déroulante cmbFields dont le type
de source ("Origine Source") est "Liste des champs".
Afin d'optimiser l'interface, le formulaire devra également avoir la
propriété "fenêtre indépendante" à "oui" pour s'afficher au-dessus de la
table.
Reste l'Etape 4 : Mettre en place le code SQL et son exécution pour
effectuer le remplacement à partir du champ sélectionné par l'utilisateur, le
texte cherché et le texte de remplacement indiqués dans le formulaire.
A noter enfin que l'idéal aurait été de fermer le formulaire de recherche
lorsque la table est fermée, mais je n'ai pas trouvé comment pour le moment
(même en ayant recours au formulaire renvoyé par Screen.ActiveDatasheet).
A noter également : Si la fenêtre active est la fenêtre Base de données,
l'objet courant et chargé peut être la table sélectionnée dans la liste des
tables même si en réalité elle n'est pas la fenêtre active).
En espérant que cela t'inspirera... (ca peut paraitre complexe, mais en
réalité c'est très simple).
