Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Lenteur sur réseau

8 réponses
Avatar
JMH
Bonjour

Un serveur SBS 2003.

3 postes XP
1 poste Vista

La base de données FILE se trouve sur le serveur.
Chaque PC a la base de données PROGRAMME en local.
Attache des tables sur FILE par le biais du chemin UNC.

Paramètres:
Mode d'ouverture: Partagé
Vérouillage: Enregistrement modifié
Ouvrir avec enregistrements vérouillé: Oui

Tous les bases locales (PRG) sont avec ces paramètres.


Tous les postes sont dans le programme Access.
Sur un poste (XP), la connexion à la base de données FILE est lente, très
lente.
J'ai même parfois dans le titre de la base "Déconnecté"
En passant d'un formulaire à l'autre, temps d'attente aussi.

Maintenant, si les autres postes sortent d'Access, ce poste XP devient très
rapide.


A noter que sur ce poste, il a accès aux données globales (documents, etc)
sur SBS 2003 et que tout est OK.

Voilà, si vous avez une piste à me donner, c'est avec plaisir.


PS: En regardant le journal des événements, j'ai trouvé le message
MSACCESS 11.0.6566 application bloquée (hungapp)
et ceci à chaque blocage.

Merci d'avance pour vos réponses.

Jean-Michel H.

8 réponses

Avatar
JMH
Rectification


Le message hungapp n'est pas systématique



"JMH" a écrit dans le message de news:

Bonjour

Un serveur SBS 2003.

3 postes XP
1 poste Vista

La base de données FILE se trouve sur le serveur.
Chaque PC a la base de données PROGRAMME en local.
Attache des tables sur FILE par le biais du chemin UNC.

Paramètres:
Mode d'ouverture: Partagé
Vérouillage: Enregistrement modifié
Ouvrir avec enregistrements vérouillé: Oui

Tous les bases locales (PRG) sont avec ces paramètres.


Tous les postes sont dans le programme Access.
Sur un poste (XP), la connexion à la base de données FILE est lente, très
lente.
J'ai même parfois dans le titre de la base "Déconnecté"
En passant d'un formulaire à l'autre, temps d'attente aussi.

Maintenant, si les autres postes sortent d'Access, ce poste XP devient
très rapide.


A noter que sur ce poste, il a accès aux données globales (documents, etc)
sur SBS 2003 et que tout est OK.

Voilà, si vous avez une piste à me donner, c'est avec plaisir.


PS: En regardant le journal des événements, j'ai trouvé le message
MSACCESS 11.0.6566 application bloquée (hungapp)
et ceci à chaque blocage.

Merci d'avance pour vos réponses.

Jean-Michel H.



Avatar
Jac
Bonjour JMH,

peut-être rien à voir, mais j'ai déjà résolu un problème de lenteur en
désactivant la correction automatique de nom (Outils / Options / Général
...).

Jac

"JMH" a écrit dans le message de news:

Rectification


Le message hungapp n'est pas systématique



"JMH" a écrit dans le message de news:

Bonjour

Un serveur SBS 2003.

3 postes XP
1 poste Vista

La base de données FILE se trouve sur le serveur.
Chaque PC a la base de données PROGRAMME en local.
Attache des tables sur FILE par le biais du chemin UNC.

Paramètres:
Mode d'ouverture: Partagé
Vérouillage: Enregistrement modifié
Ouvrir avec enregistrements vérouillé: Oui

Tous les bases locales (PRG) sont avec ces paramètres.


Tous les postes sont dans le programme Access.
Sur un poste (XP), la connexion à la base de données FILE est lente, très
lente.
J'ai même parfois dans le titre de la base "Déconnecté"
En passant d'un formulaire à l'autre, temps d'attente aussi.

Maintenant, si les autres postes sortent d'Access, ce poste XP devient
très rapide.


A noter que sur ce poste, il a accès aux données globales (documents,
etc) sur SBS 2003 et que tout est OK.

Voilà, si vous avez une piste à me donner, c'est avec plaisir.


PS: En regardant le journal des événements, j'ai trouvé le message
MSACCESS 11.0.6566 application bloquée (hungapp)
et ceci à chaque blocage.

Merci d'avance pour vos réponses.

Jean-Michel H.







Avatar
JMH
Salut
Hélas ce n'est pas ça.

Merci


"Jac" a écrit dans le message de news:

Bonjour JMH,

peut-être rien à voir, mais j'ai déjà résolu un problème de lenteur en
désactivant la correction automatique de nom (Outils / Options / Général
...).

Jac

"JMH" a écrit dans le message de news:

Rectification


Le message hungapp n'est pas systématique



"JMH" a écrit dans le message de news:

Bonjour

Un serveur SBS 2003.

3 postes XP
1 poste Vista

La base de données FILE se trouve sur le serveur.
Chaque PC a la base de données PROGRAMME en local.
Attache des tables sur FILE par le biais du chemin UNC.

Paramètres:
Mode d'ouverture: Partagé
Vérouillage: Enregistrement modifié
Ouvrir avec enregistrements vérouillé: Oui

Tous les bases locales (PRG) sont avec ces paramètres.


Tous les postes sont dans le programme Access.
Sur un poste (XP), la connexion à la base de données FILE est lente,
très lente.
J'ai même parfois dans le titre de la base "Déconnecté"
En passant d'un formulaire à l'autre, temps d'attente aussi.

Maintenant, si les autres postes sortent d'Access, ce poste XP devient
très rapide.


A noter que sur ce poste, il a accès aux données globales (documents,
etc) sur SBS 2003 et que tout est OK.

Voilà, si vous avez une piste à me donner, c'est avec plaisir.


PS: En regardant le journal des événements, j'ai trouvé le message
MSACCESS 11.0.6566 application bloquée (hungapp)
et ceci à chaque blocage.

Merci d'avance pour vos réponses.

Jean-Michel H.











Avatar
JMH
Re

Je suis sur 4 postes et je fais des essais.

Access sur 1 poste = OK
Access sur 2ème poste = OK
Access sur 3ème poste = commence à être lent (sur ce poste)
Access sur 4ème poste = très lent sur tous les postes


J'espère quand même qu'Access me permette de travailler sur 4 poste en même
temps. en plus que c'est des base très petites (10nm pour le données, 3 mb
pour les programmes)

Je cherche où?

A noter que les autres accès sur le répertoire des documents est absolument
parfait.

Je rame..

Merci d'avance pour votre aide.

JMH



"JMH" a écrit dans le message de news:

Bonjour

Un serveur SBS 2003.

3 postes XP
1 poste Vista

La base de données FILE se trouve sur le serveur.
Chaque PC a la base de données PROGRAMME en local.
Attache des tables sur FILE par le biais du chemin UNC.

Paramètres:
Mode d'ouverture: Partagé
Vérouillage: Enregistrement modifié
Ouvrir avec enregistrements vérouillé: Oui

Tous les bases locales (PRG) sont avec ces paramètres.


Tous les postes sont dans le programme Access.
Sur un poste (XP), la connexion à la base de données FILE est lente, très
lente.
J'ai même parfois dans le titre de la base "Déconnecté"
En passant d'un formulaire à l'autre, temps d'attente aussi.

Maintenant, si les autres postes sortent d'Access, ce poste XP devient
très rapide.


A noter que sur ce poste, il a accès aux données globales (documents, etc)
sur SBS 2003 et que tout est OK.

Voilà, si vous avez une piste à me donner, c'est avec plaisir.


PS: En regardant le journal des événements, j'ai trouvé le message
MSACCESS 11.0.6566 application bloquée (hungapp)
et ceci à chaque blocage.

Merci d'avance pour vos réponses.

Jean-Michel H.



Avatar
JMH
Bonjour

C'est les anti-virus qui me bloquaient tout ça.



"JMH" a écrit dans le message de news:

Bonjour

Un serveur SBS 2003.

3 postes XP
1 poste Vista

La base de données FILE se trouve sur le serveur.
Chaque PC a la base de données PROGRAMME en local.
Attache des tables sur FILE par le biais du chemin UNC.

Paramètres:
Mode d'ouverture: Partagé
Vérouillage: Enregistrement modifié
Ouvrir avec enregistrements vérouillé: Oui

Tous les bases locales (PRG) sont avec ces paramètres.


Tous les postes sont dans le programme Access.
Sur un poste (XP), la connexion à la base de données FILE est lente, très
lente.
J'ai même parfois dans le titre de la base "Déconnecté"
En passant d'un formulaire à l'autre, temps d'attente aussi.

Maintenant, si les autres postes sortent d'Access, ce poste XP devient
très rapide.


A noter que sur ce poste, il a accès aux données globales (documents, etc)
sur SBS 2003 et que tout est OK.

Voilà, si vous avez une piste à me donner, c'est avec plaisir.


PS: En regardant le journal des événements, j'ai trouvé le message
MSACCESS 11.0.6566 application bloquée (hungapp)
et ceci à chaque blocage.

Merci d'avance pour vos réponses.

Jean-Michel H.



Avatar
jerome crevecoeur
Des solutions en vrac à tester

Cordialement


Causes connues de la lenteur d'une appli access avec
tables liées
Même parfois un peu loufoque, ces solutions ont toutes
été éprouvées ! Ne rien laisser au hasard, donc.

- sur le serveur, vérifier l'écran de veille: un écran de
veille gourmand (genre Boules 3D), sur NT, peut accaparer
jusqu'à 90% du CPU. Incroyabe mas vrai!
Solutions: désactiver l'écran de veille ou affecter
un écran de veille type Black Screen, peu glouton

- dans les tables, passer en mode création, afficher les
propriétés des tables, et régler la propriété Sous
feuille de données (sub data sheet je crois) sur [Aucun]
([none])
Access a tendance à rapatrier toutes les "sous-
données" (tables en relations un à plusieurs en
général) , ce qui alourdit considérablement le trafic
d'infos dans les tuyaux

- toujours dans les tables, mais aussi dans l'appli:
Outils/Options/onglet général .. s'assurer d'avoir
décoché l'option "suivi correction automatique des noms"
(attention, il est possible que certains états perdent
leur mise en forme) .. conséquence, certains états
peuvent s'ouvrir jusqu'à 4 fois plus vite (merci
Microsoft)

- dans la série incroyable, on poursuit: placer la base
de données source (backend) sur la racine du serveur
plutôt que dans une multitude de sous-répertoire.
a compléter par la réduction du nom du fichier source :
ex: c:repertoire1repertoire2repertoire3repertoire4
MaBaseDeDonnéesSourceAccess2000.mdb sera moins
performant (tables liées) que c:repertoire1Base.mdb

- Anti-virus: un cas fréquent de lenteur: si vous
disposez de norton Anti virus (une des 3/4 dernières
versions), s'assurer que le fichier source sera exclus du
scan
et que l'anti-virus n'analyse QUE les disques locaux, et
pas les lecteurs réseau

- S'assurer que vous disposez bien du dernier moteur Jet,
à moins que, puisque vous me parlez d'internet, vous
n'utilisiez le moteur MSDE
Q302496 ACC2000: Queries Slower After You Install MS Jet
4.0 SP4 or SP5
<http://support.microsoft.com/support/kb/articles/q302/4/9
6.asp>

- ce qui a fonctionné pour moi (mais pour internet,
faudra adapter ;-) ):
la base front end, lorsqu'elle tente d'accéder à la base
backend (tables liées à un fichier source), rencontre un
fichier lockFile (*.ldb)
Access tente alors de supprimer ce fichier, mais n'y
parvient pas (puisque quelqu'un est déjà connecté sur la
base source). Après une quinzaine de tentatives,
infructueuses, Access renvoie enfin le jeu
d'enregistrement. Pour éviter cela, voilà ce que j'ai mis
en place:
afin d'établir une connection permanente avec la base en
backend, et donc de prévenir ce probème, créez

-un formulaire, appelons-le "frmdummy" (formulaire
stupide ;-) )
- une table "tbldummy" (avec un champ simple, n'importe
quel format, n'importe quel nom)
-dans un module standard, déclarez une variable globale
de type recordset
ex: Public rsAlwaysOpen As
Recordset
-Dans l'évènement sur ouverture du formulaire frmdummy
(OnOpen), ouvrez un recordset
Private Sub Form_Open(Cancel As Integer)
Set rsAlwaysOpen = CurrentDb.OpenRecordset
("DummyTable")
End Sub

-Dans l'évènement sur fermeture du formulaire frmdummy
(OnClose), fermez le recordset
Private Sub Form_Close()
rsAlwaysOpen.Close
Set rsAlwaysOpen = Nothing
End Sub

- au lancement de la db, ouvrez ce formulaire en premier,
avec visiblelse
ce formulaire restera ouvert jusqu'à la fermeture de
l'appli.

Résultat: un traitement de 5 à 10X plus rapide ...

Re

Je suis sur 4 postes et je fais des essais.

Access sur 1 poste = OK
Access sur 2ème poste = OK
Access sur 3ème poste = commence à être lent (sur ce poste)
Access sur 4ème poste = très lent sur tous les postes


J'espère quand même qu'Access me permette de travailler sur 4 poste en même
temps. en plus que c'est des base très petites (10nm pour le donnée s, 3 mb
pour les programmes)

Je cherche où?

A noter que les autres accès sur le répertoire des documents est ab solument
parfait.

Je rame..

Merci d'avance pour votre aide.

JMH



"JMH" a écrit dans le message de news:

Bonjour

Un serveur SBS 2003.

3 postes XP
1 poste Vista

La base de données FILE se trouve sur le serveur.
Chaque PC a la base de données PROGRAMME en local.
Attache des tables sur FILE par le biais du chemin UNC.

Paramètres:
Mode d'ouverture: Partagé
Vérouillage: Enregistrement modifié
Ouvrir avec enregistrements vérouillé: Oui

Tous les bases locales (PRG) sont avec ces paramètres.


Tous les postes sont dans le programme Access.
Sur un poste (XP), la connexion à la base de données FILE est lent e, très
lente.
J'ai même parfois dans le titre de la base "Déconnecté"
En passant d'un formulaire à l'autre, temps d'attente aussi.

Maintenant, si les autres postes sortent d'Access, ce poste XP devient
très rapide.


A noter que sur ce poste, il a accès aux données globales (documen ts, etc)
sur SBS 2003 et que tout est OK.

Voilà, si vous avez une piste à me donner, c'est avec plaisir.


PS: En regardant le journal des événements, j'ai trouvé le messa ge
MSACCESS 11.0.6566 application bloquée (hungapp)
et ceci à chaque blocage.

Merci d'avance pour vos réponses.

Jean-Michel H.







Avatar
JMH
Bonjour Jerôme

J'avais un problème entre autre d'anti-virus que j'ai réglé.
Donc ça va mieux.

Par contre je vais étudier l'ensemble de ta réponse et réadapter certaines
choses dans mon programme.

Effectivement, les problèmes que tu décris me laisse sans voix.
Je vais les appliquer.

Je te remercie infiniment pour ta réponse complète.
C'est sympa de ta part.

Bonne soirée.

Jean-Michel H.



"jerome crevecoeur"
a écrit dans le message de news:
Des solutions en vrac à tester

Cordialement


Causes connues de la lenteur d'une appli access avec
tables liées
Même parfois un peu loufoque, ces solutions ont toutes
été éprouvées ! Ne rien laisser au hasard, donc.

- sur le serveur, vérifier l'écran de veille: un écran de
veille gourmand (genre Boules 3D), sur NT, peut accaparer
jusqu'à 90% du CPU. Incroyabe mas vrai!
Solutions: désactiver l'écran de veille ou affecter
un écran de veille type Black Screen, peu glouton

- dans les tables, passer en mode création, afficher les
propriétés des tables, et régler la propriété Sous
feuille de données (sub data sheet je crois) sur [Aucun]
([none])
Access a tendance à rapatrier toutes les "sous-
données" (tables en relations un à plusieurs en
général) , ce qui alourdit considérablement le trafic
d'infos dans les tuyaux

- toujours dans les tables, mais aussi dans l'appli:
Outils/Options/onglet général .. s'assurer d'avoir
décoché l'option "suivi correction automatique des noms"
(attention, il est possible que certains états perdent
leur mise en forme) .. conséquence, certains états
peuvent s'ouvrir jusqu'à 4 fois plus vite (merci
Microsoft)

- dans la série incroyable, on poursuit: placer la base
de données source (backend) sur la racine du serveur
plutôt que dans une multitude de sous-répertoire.
a compléter par la réduction du nom du fichier source :
ex: c:repertoire1repertoire2repertoire3repertoire4
MaBaseDeDonnéesSourceAccess2000.mdb sera moins
performant (tables liées) que c:repertoire1Base.mdb

- Anti-virus: un cas fréquent de lenteur: si vous
disposez de norton Anti virus (une des 3/4 dernières
versions), s'assurer que le fichier source sera exclus du
scan
et que l'anti-virus n'analyse QUE les disques locaux, et
pas les lecteurs réseau

- S'assurer que vous disposez bien du dernier moteur Jet,
à moins que, puisque vous me parlez d'internet, vous
n'utilisiez le moteur MSDE
Q302496 ACC2000: Queries Slower After You Install MS Jet
4.0 SP4 or SP5
<http://support.microsoft.com/support/kb/articles/q302/4/9
6.asp>

- ce qui a fonctionné pour moi (mais pour internet,
faudra adapter ;-) ):
la base front end, lorsqu'elle tente d'accéder à la base
backend (tables liées à un fichier source), rencontre un
fichier lockFile (*.ldb)
Access tente alors de supprimer ce fichier, mais n'y
parvient pas (puisque quelqu'un est déjà connecté sur la
base source). Après une quinzaine de tentatives,
infructueuses, Access renvoie enfin le jeu
d'enregistrement. Pour éviter cela, voilà ce que j'ai mis
en place:
afin d'établir une connection permanente avec la base en
backend, et donc de prévenir ce probème, créez

-un formulaire, appelons-le "frmdummy" (formulaire
stupide ;-) )
- une table "tbldummy" (avec un champ simple, n'importe
quel format, n'importe quel nom)
-dans un module standard, déclarez une variable globale
de type recordset
ex: Public rsAlwaysOpen As
Recordset
-Dans l'évènement sur ouverture du formulaire frmdummy
(OnOpen), ouvrez un recordset
Private Sub Form_Open(Cancel As Integer)
Set rsAlwaysOpen = CurrentDb.OpenRecordset
("DummyTable")
End Sub

-Dans l'évènement sur fermeture du formulaire frmdummy
(OnClose), fermez le recordset
Private Sub Form_Close()
rsAlwaysOpen.Close
Set rsAlwaysOpen = Nothing
End Sub

- au lancement de la db, ouvrez ce formulaire en premier,
avec visibleúlse
ce formulaire restera ouvert jusqu'à la fermeture de
l'appli.

Résultat: un traitement de 5 à 10X plus rapide ...

Re

Je suis sur 4 postes et je fais des essais.

Access sur 1 poste = OK
Access sur 2ème poste = OK
Access sur 3ème poste = commence à être lent (sur ce poste)
Access sur 4ème poste = très lent sur tous les postes


J'espère quand même qu'Access me permette de travailler sur 4 poste en
même temps. en plus que c'est des base très petites (10nm pour le données,
3 mb pour les programmes)

Je cherche où?

A noter que les autres accès sur le répertoire des documents est
absolument parfait.

Je rame..

Merci d'avance pour votre aide.

JMH



"JMH" a écrit dans le message de news:

Bonjour

Un serveur SBS 2003.

3 postes XP
1 poste Vista

La base de données FILE se trouve sur le serveur.
Chaque PC a la base de données PROGRAMME en local.
Attache des tables sur FILE par le biais du chemin UNC.

Paramètres:
Mode d'ouverture: Partagé
Vérouillage: Enregistrement modifié
Ouvrir avec enregistrements vérouillé: Oui

Tous les bases locales (PRG) sont avec ces paramètres.


Tous les postes sont dans le programme Access.
Sur un poste (XP), la connexion à la base de données FILE est lente, très
lente.
J'ai même parfois dans le titre de la base "Déconnecté"
En passant d'un formulaire à l'autre, temps d'attente aussi.

Maintenant, si les autres postes sortent d'Access, ce poste XP devient
très rapide.


A noter que sur ce poste, il a accès aux données globales (documents,
etc) sur SBS 2003 et que tout est OK.

Voilà, si vous avez une piste à me donner, c'est avec plaisir.


PS: En regardant le journal des événements, j'ai trouvé le message
MSACCESS 11.0.6566 application bloquée (hungapp)
et ceci à chaque blocage.

Merci d'avance pour vos réponses.

Jean-Michel H.







Avatar
jerome crevecoeur
de rien , on est là pour s'entraider :-)
Bonjour Jerôme

J'avais un problème entre autre d'anti-virus que j'ai réglé.
Donc ça va mieux.

Par contre je vais étudier l'ensemble de ta réponse et réadapter certaines
choses dans mon programme.

Effectivement, les problèmes que tu décris me laisse sans voix.
Je vais les appliquer.

Je te remercie infiniment pour ta réponse complète.
C'est sympa de ta part.

Bonne soirée.

Jean-Michel H.



"jerome crevecoeur" o.fr>
a écrit dans le message de news: l...
Des solutions en vrac à tester

Cordialement


Causes connues de la lenteur d'une appli access avec
tables liées
Même parfois un peu loufoque, ces solutions ont toutes
été éprouvées ! Ne rien laisser au hasard, donc.

- sur le serveur, vérifier l'écran de veille: un écran de
veille gourmand (genre Boules 3D), sur NT, peut accaparer
jusqu'à 90% du CPU. Incroyabe mas vrai!
Solutions: désactiver l'écran de veille ou affecter
un écran de veille type Black Screen, peu glouton

- dans les tables, passer en mode création, afficher les
propriétés des tables, et régler la propriété Sous
feuille de données (sub data sheet je crois) sur [Aucun]
([none])
Access a tendance à rapatrier toutes les "sous-
données" (tables en relations un à plusieurs en
général) , ce qui alourdit considérablement le trafic
d'infos dans les tuyaux

- toujours dans les tables, mais aussi dans l'appli:
Outils/Options/onglet général .. s'assurer d'avoir
décoché l'option "suivi correction automatique des noms"
(attention, il est possible que certains états perdent
leur mise en forme) .. conséquence, certains états
peuvent s'ouvrir jusqu'à 4 fois plus vite (merci
Microsoft)

- dans la série incroyable, on poursuit: placer la base
de données source (backend) sur la racine du serveur
plutôt que dans une multitude de sous-répertoire.
a compléter par la réduction du nom du fichier source :
ex: c:repertoire1repertoire2repertoire3repertoire4
MaBaseDeDonnéesSourceAccess2000.mdb sera moins
performant (tables liées) que c:repertoire1Base.mdb

- Anti-virus: un cas fréquent de lenteur: si vous
disposez de norton Anti virus (une des 3/4 dernières
versions), s'assurer que le fichier source sera exclus du
scan
et que l'anti-virus n'analyse QUE les disques locaux, et
pas les lecteurs réseau

- S'assurer que vous disposez bien du dernier moteur Jet,
à moins que, puisque vous me parlez d'internet, vous
n'utilisiez le moteur MSDE
Q302496 ACC2000: Queries Slower After You Install MS Jet
4.0 SP4 or SP5
<http://support.microsoft.com/support/kb/articles/q302/4/9
6.asp>

- ce qui a fonctionné pour moi (mais pour internet,
faudra adapter ;-) ):
la base front end, lorsqu'elle tente d'accéder à la base
backend (tables liées à un fichier source), rencontre un
fichier lockFile (*.ldb)
Access tente alors de supprimer ce fichier, mais n'y
parvient pas (puisque quelqu'un est déjà connecté sur la
base source). Après une quinzaine de tentatives,
infructueuses, Access renvoie enfin le jeu
d'enregistrement. Pour éviter cela, voilà ce que j'ai mis
en place:
afin d'établir une connection permanente avec la base en
backend, et donc de prévenir ce probème, créez

-un formulaire, appelons-le "frmdummy" (formulaire
stupide ;-) )
- une table "tbldummy" (avec un champ simple, n'importe
quel format, n'importe quel nom)
-dans un module standard, déclarez une variable globale
de type recordset
ex: Public rsAlwaysOpen As
Recordset
-Dans l'évènement sur ouverture du formulaire frmdummy
(OnOpen), ouvrez un recordset
Private Sub Form_Open(Cancel As Integer)
Set rsAlwaysOpen = CurrentDb.OpenRecordset
("DummyTable")
End Sub

-Dans l'évènement sur fermeture du formulaire frmdummy
(OnClose), fermez le recordset
Private Sub Form_Close()
rsAlwaysOpen.Close
Set rsAlwaysOpen = Nothing
End Sub

- au lancement de la db, ouvrez ce formulaire en premier,
avec visiblelse
ce formulaire restera ouvert jusqu'à la fermeture de
l'appli.

Résultat: un traitement de 5 à 10X plus rapide ...

Re

Je suis sur 4 postes et je fais des essais.

Access sur 1 poste = OK
Access sur 2ème poste = OK
Access sur 3ème poste = commence à être lent (sur ce poste)
Access sur 4ème poste = très lent sur tous les postes


J'espère quand même qu'Access me permette de travailler sur 4 post e en
même temps. en plus que c'est des base très petites (10nm pour le données,
3 mb pour les programmes)

Je cherche où?

A noter que les autres accès sur le répertoire des documents est
absolument parfait.

Je rame..

Merci d'avance pour votre aide.

JMH



"JMH" a écrit dans le message de news:

Bonjour

Un serveur SBS 2003.

3 postes XP
1 poste Vista

La base de données FILE se trouve sur le serveur.
Chaque PC a la base de données PROGRAMME en local.
Attache des tables sur FILE par le biais du chemin UNC.

Paramètres:
Mode d'ouverture: Partagé
Vérouillage: Enregistrement modifié
Ouvrir avec enregistrements vérouillé: Oui

Tous les bases locales (PRG) sont avec ces paramètres.


Tous les postes sont dans le programme Access.
Sur un poste (XP), la connexion à la base de données FILE est len te, très
lente.
J'ai même parfois dans le titre de la base "Déconnecté"
En passant d'un formulaire à l'autre, temps d'attente aussi.

Maintenant, si les autres postes sortent d'Access, ce poste XP devien t
très rapide.


A noter que sur ce poste, il a accès aux données globales (docume nts,
etc) sur SBS 2003 et que tout est OK.

Voilà, si vous avez une piste à me donner, c'est avec plaisir.


PS: En regardant le journal des événements, j'ai trouvé le mess age
MSACCESS 11.0.6566 application bloquée (hungapp)
et ceci à chaque blocage.

Merci d'avance pour vos réponses.

Jean-Michel H.