Salut,
"Nathalie Lebas"
| Je constate depuis 2 semaines, la déterioration d'un des formulaires de ma
| base et seulement un. Je suis en version 2000 d'accès. Ma base fait 113 000
| ko.
| Par contre, mon formulaire contient plusieurs onglets.
| Le semaine dernière, j'ai créé une nouvelle base et importé les infos de la
| base de production puis compacté et les performances sont redevenues normales.
Le compactage est une action absolument **obligatoire** lorsque
la base Access est utilisée en saisie. Selon le volume des saisies
et suppression, à faire journellement.
| Cette base est sur un serveur et les utilisateurs y accèdent par raccourci.
Si tu veux dire que tout le monde dispose sur son bureau d'un raccourci
vers la même et unique "base" Access qui elle se trouve sur le serveur,
c'est une mauvaise méthode.
- Il faut absolument utiliser une base dorsale placée sur le serveur
(celle qui ne contient que les tables)
et sur le poste de chacun, une copie de la base frontale
(qui contient tout, sauf les tables)
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Salut,
"Nathalie Lebas"
| Je constate depuis 2 semaines, la déterioration d'un des formulaires de ma
| base et seulement un. Je suis en version 2000 d'accès. Ma base fait 113 000
| ko.
| Par contre, mon formulaire contient plusieurs onglets.
| Le semaine dernière, j'ai créé une nouvelle base et importé les infos de la
| base de production puis compacté et les performances sont redevenues normales.
Le compactage est une action absolument **obligatoire** lorsque
la base Access est utilisée en saisie. Selon le volume des saisies
et suppression, à faire journellement.
| Cette base est sur un serveur et les utilisateurs y accèdent par raccourci.
Si tu veux dire que tout le monde dispose sur son bureau d'un raccourci
vers la même et unique "base" Access qui elle se trouve sur le serveur,
c'est une mauvaise méthode.
- Il faut absolument utiliser une base dorsale placée sur le serveur
(celle qui ne contient que les tables)
et sur le poste de chacun, une copie de la base frontale
(qui contient tout, sauf les tables)
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Salut,
"Nathalie Lebas"
| Je constate depuis 2 semaines, la déterioration d'un des formulaires de ma
| base et seulement un. Je suis en version 2000 d'accès. Ma base fait 113 000
| ko.
| Par contre, mon formulaire contient plusieurs onglets.
| Le semaine dernière, j'ai créé une nouvelle base et importé les infos de la
| base de production puis compacté et les performances sont redevenues normales.
Le compactage est une action absolument **obligatoire** lorsque
la base Access est utilisée en saisie. Selon le volume des saisies
et suppression, à faire journellement.
| Cette base est sur un serveur et les utilisateurs y accèdent par raccourci.
Si tu veux dire que tout le monde dispose sur son bureau d'un raccourci
vers la même et unique "base" Access qui elle se trouve sur le serveur,
c'est une mauvaise méthode.
- Il faut absolument utiliser une base dorsale placée sur le serveur
(celle qui ne contient que les tables)
et sur le poste de chacun, une copie de la base frontale
(qui contient tout, sauf les tables)
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Salut,
"Nathalie Lebas"
| Le compactage ne suffit pas à solutionner ce problème malheureusement.
| J'aimerais travailler avec des tables liées. J'ai déjà fais des essais sur
| une base plus petite et c'est la catastrophe. Les temps de réponses sont
| lamentables et lorsqu'il y a plusieurs utilisateurs, ils sont bloqués.
Cela montre simplement que toutes les erreurs cumulées, ne se vient
pas beaucoup lorsque la base est en local, mais apparaîssent
décuplés lorsque la base dorsale est distante.
Un exemple:
Un formulaire avec une série de sous-formulaires disposés sur des
onglets d'un contrôle d'onglet. Lorsque tous ces sous-formulaires
ont une source déjà définie à l'ouverture du formulaire principal,
il ne faut pas s'étonner de la performance médiocre d'un tel "montage",
surtout en réseau !
|C'est
| pour cela que je travaille avec une seule base par obligation.
Il n'y à pas d'obligation !
Seulement de la compétence et du travail bien fait (ou l'inverse) ;-)
| J'ai déjà évoqué ce problème avec Tisane il y a un moment car ma base
| grossie et j'aurrais souhaité deux bases.
Sauf pour une petite base locale, il faut toujours scinder une base Access
en frontale et dorsale. Et c'est absolument obligatoire lorsqu'il y a
plusieurs utilisateurs sumultanés !
| Peut-être que je ne fais pas les choses correstement, je ne sais pas.
| J'avais procédé ainsi :
| - une base avec les données seules sur le serveur
| - une base avec le reste sur les postes utilisateurs
| - les tables de la première base sont liées à la deuxième.
C'est un départ - mais ne suffit pas à empêcher l'unsine à gaz...
| Tisane m'avait suggéré de mettre les deux bases dans le même répertoire du
| serveur mais je n'ai pas encore eu le temps de faire des essais avec tous mes
| utilisateurs.
Non, la frontale doit se trouver sur le poste de l'utilisateur.
A défaut, les formulaires, états et autres objets doivent également
transiter par le réseau.
| Aujourd'hui, je m'inquiète de voir qu'un formulaire puisse se dégrader au
| fil du temps et pas les autres.
Cette phrase indique que tu ne "saisis" pas bien le fonctionnement...
Un formulaire ne se dégrade pas - hors une éventuellement corruption.
Ce sont les temps de tranfert qui se dégradent et cela est le signe
caractéristique d'une base et de solutions non optimales.
Lorsque la conception est correcte, une base peut tourner aussi bien
avec 100.000 enregistrements qu'avec 2.000 !
Pour rappel, c'est lors de la conception même (sur papier) d'une base
que l'on doit penser à l'optimisation et au trafic engendré par les choix
fait pour construire une base.
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Salut,
"Nathalie Lebas"
| Le compactage ne suffit pas à solutionner ce problème malheureusement.
| J'aimerais travailler avec des tables liées. J'ai déjà fais des essais sur
| une base plus petite et c'est la catastrophe. Les temps de réponses sont
| lamentables et lorsqu'il y a plusieurs utilisateurs, ils sont bloqués.
Cela montre simplement que toutes les erreurs cumulées, ne se vient
pas beaucoup lorsque la base est en local, mais apparaîssent
décuplés lorsque la base dorsale est distante.
Un exemple:
Un formulaire avec une série de sous-formulaires disposés sur des
onglets d'un contrôle d'onglet. Lorsque tous ces sous-formulaires
ont une source déjà définie à l'ouverture du formulaire principal,
il ne faut pas s'étonner de la performance médiocre d'un tel "montage",
surtout en réseau !
|C'est
| pour cela que je travaille avec une seule base par obligation.
Il n'y à pas d'obligation !
Seulement de la compétence et du travail bien fait (ou l'inverse) ;-)
| J'ai déjà évoqué ce problème avec Tisane il y a un moment car ma base
| grossie et j'aurrais souhaité deux bases.
Sauf pour une petite base locale, il faut toujours scinder une base Access
en frontale et dorsale. Et c'est absolument obligatoire lorsqu'il y a
plusieurs utilisateurs sumultanés !
| Peut-être que je ne fais pas les choses correstement, je ne sais pas.
| J'avais procédé ainsi :
| - une base avec les données seules sur le serveur
| - une base avec le reste sur les postes utilisateurs
| - les tables de la première base sont liées à la deuxième.
C'est un départ - mais ne suffit pas à empêcher l'unsine à gaz...
| Tisane m'avait suggéré de mettre les deux bases dans le même répertoire du
| serveur mais je n'ai pas encore eu le temps de faire des essais avec tous mes
| utilisateurs.
Non, la frontale doit se trouver sur le poste de l'utilisateur.
A défaut, les formulaires, états et autres objets doivent également
transiter par le réseau.
| Aujourd'hui, je m'inquiète de voir qu'un formulaire puisse se dégrader au
| fil du temps et pas les autres.
Cette phrase indique que tu ne "saisis" pas bien le fonctionnement...
Un formulaire ne se dégrade pas - hors une éventuellement corruption.
Ce sont les temps de tranfert qui se dégradent et cela est le signe
caractéristique d'une base et de solutions non optimales.
Lorsque la conception est correcte, une base peut tourner aussi bien
avec 100.000 enregistrements qu'avec 2.000 !
Pour rappel, c'est lors de la conception même (sur papier) d'une base
que l'on doit penser à l'optimisation et au trafic engendré par les choix
fait pour construire une base.
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Salut,
"Nathalie Lebas"
| Le compactage ne suffit pas à solutionner ce problème malheureusement.
| J'aimerais travailler avec des tables liées. J'ai déjà fais des essais sur
| une base plus petite et c'est la catastrophe. Les temps de réponses sont
| lamentables et lorsqu'il y a plusieurs utilisateurs, ils sont bloqués.
Cela montre simplement que toutes les erreurs cumulées, ne se vient
pas beaucoup lorsque la base est en local, mais apparaîssent
décuplés lorsque la base dorsale est distante.
Un exemple:
Un formulaire avec une série de sous-formulaires disposés sur des
onglets d'un contrôle d'onglet. Lorsque tous ces sous-formulaires
ont une source déjà définie à l'ouverture du formulaire principal,
il ne faut pas s'étonner de la performance médiocre d'un tel "montage",
surtout en réseau !
|C'est
| pour cela que je travaille avec une seule base par obligation.
Il n'y à pas d'obligation !
Seulement de la compétence et du travail bien fait (ou l'inverse) ;-)
| J'ai déjà évoqué ce problème avec Tisane il y a un moment car ma base
| grossie et j'aurrais souhaité deux bases.
Sauf pour une petite base locale, il faut toujours scinder une base Access
en frontale et dorsale. Et c'est absolument obligatoire lorsqu'il y a
plusieurs utilisateurs sumultanés !
| Peut-être que je ne fais pas les choses correstement, je ne sais pas.
| J'avais procédé ainsi :
| - une base avec les données seules sur le serveur
| - une base avec le reste sur les postes utilisateurs
| - les tables de la première base sont liées à la deuxième.
C'est un départ - mais ne suffit pas à empêcher l'unsine à gaz...
| Tisane m'avait suggéré de mettre les deux bases dans le même répertoire du
| serveur mais je n'ai pas encore eu le temps de faire des essais avec tous mes
| utilisateurs.
Non, la frontale doit se trouver sur le poste de l'utilisateur.
A défaut, les formulaires, états et autres objets doivent également
transiter par le réseau.
| Aujourd'hui, je m'inquiète de voir qu'un formulaire puisse se dégrader au
| fil du temps et pas les autres.
Cette phrase indique que tu ne "saisis" pas bien le fonctionnement...
Un formulaire ne se dégrade pas - hors une éventuellement corruption.
Ce sont les temps de tranfert qui se dégradent et cela est le signe
caractéristique d'une base et de solutions non optimales.
Lorsque la conception est correcte, une base peut tourner aussi bien
avec 100.000 enregistrements qu'avec 2.000 !
Pour rappel, c'est lors de la conception même (sur papier) d'une base
que l'on doit penser à l'optimisation et au trafic engendré par les choix
fait pour construire une base.
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
| J'ai déjà évoqué ce problème avec Tisane il y a un moment car ma base
| grossie et j'aurrais souhaité deux bases.
Sauf pour une petite base locale, il faut toujours scinder une base Access
en frontale et dorsale. Et c'est absolument obligatoire lorsqu'il y a
plusieurs utilisateurs sumultanés !
[...]
| Tisane m'avait suggéré de mettre les deux bases dans le même répertoire
du
| serveur mais je n'ai pas encore eu le temps de faire des essais avec
tous mes
| utilisateurs.
Non, la frontale doit se trouver sur le poste de l'utilisateur.
A défaut, les formulaires, états et autres objets doivent également
transiter par le réseau.
[...]
| J'ai déjà évoqué ce problème avec Tisane il y a un moment car ma base
| grossie et j'aurrais souhaité deux bases.
Sauf pour une petite base locale, il faut toujours scinder une base Access
en frontale et dorsale. Et c'est absolument obligatoire lorsqu'il y a
plusieurs utilisateurs sumultanés !
[...]
| Tisane m'avait suggéré de mettre les deux bases dans le même répertoire
du
| serveur mais je n'ai pas encore eu le temps de faire des essais avec
tous mes
| utilisateurs.
Non, la frontale doit se trouver sur le poste de l'utilisateur.
A défaut, les formulaires, états et autres objets doivent également
transiter par le réseau.
[...]
| J'ai déjà évoqué ce problème avec Tisane il y a un moment car ma base
| grossie et j'aurrais souhaité deux bases.
Sauf pour une petite base locale, il faut toujours scinder une base Access
en frontale et dorsale. Et c'est absolument obligatoire lorsqu'il y a
plusieurs utilisateurs sumultanés !
[...]
| Tisane m'avait suggéré de mettre les deux bases dans le même répertoire
du
| serveur mais je n'ai pas encore eu le temps de faire des essais avec
tous mes
| utilisateurs.
Non, la frontale doit se trouver sur le poste de l'utilisateur.
A défaut, les formulaires, états et autres objets doivent également
transiter par le réseau.
[...]
Hello Pierre "3stone",| J'ai déjà évoqué ce problème avec Tisane il y a un moment car ma base
| grossie et j'aurrais souhaité deux bases.
Sauf pour une petite base locale, il faut toujours scinder une base Access
en frontale et dorsale. Et c'est absolument obligatoire lorsqu'il y a
plusieurs utilisateurs sumultanés !
[...]| Tisane m'avait suggéré de mettre les deux bases dans le même répertoire
du
| serveur mais je n'ai pas encore eu le temps de faire des essais avec
tous mes
| utilisateurs.
Non, la frontale doit se trouver sur le poste de l'utilisateur.
A défaut, les formulaires, états et autres objets doivent également
transiter par le réseau.
[...]
Nous sommes parfaitement d'accord. L'information est toujours déformée au
fil du temps...
http://groups.google.fr/group/microsoft.public.fr.access/browse_thread/thread/d7e676e3f179e992/180a99b7ad2252a9?lnk=gst&q=nathalie+lebas&rnum=3#180a99b7ad2252a9
et notamment :
http://groups.google.fr/group/microsoft.public.fr.access/msg/ea24dadf742e1a2a
La suggestion de mettre les 2 bases dans le même dossier sur le serveur ne
valait que pour tester la vitesse, puisque Nathalie a essayé de mettre la
frontale sur le poste client et s'est retrouvé avec des lenteurs plus
importantes qu'une seule base sur le serveur.
Toutefois, j'ai plusieurs bases (de moindre importance) dont le code et les
données sont placés uniquement sur un serveur (pour des raisons
"historiques") et cela fonctionne depuis plusieurs années sans problème et
avec une vitesse honorable. Le transfert des objets ne se fait qu'une seule
fois lors de la première utilisation dans la session.
Je redoute plutôt la corruption de la base "code" qui bloquerait tout le
monde. Ce qui n'est pas le cas avec la frontale sur poste client.
Mais, pour revenir au problème de Nathalie (coucou !) et comme je lui ai
déjà dit, 510 formulaires, 940 requêtes et 270 états... me laissent songeuse
;-)
--
Tisane
Hello Pierre "3stone",
| J'ai déjà évoqué ce problème avec Tisane il y a un moment car ma base
| grossie et j'aurrais souhaité deux bases.
Sauf pour une petite base locale, il faut toujours scinder une base Access
en frontale et dorsale. Et c'est absolument obligatoire lorsqu'il y a
plusieurs utilisateurs sumultanés !
[...]
| Tisane m'avait suggéré de mettre les deux bases dans le même répertoire
du
| serveur mais je n'ai pas encore eu le temps de faire des essais avec
tous mes
| utilisateurs.
Non, la frontale doit se trouver sur le poste de l'utilisateur.
A défaut, les formulaires, états et autres objets doivent également
transiter par le réseau.
[...]
Nous sommes parfaitement d'accord. L'information est toujours déformée au
fil du temps...
http://groups.google.fr/group/microsoft.public.fr.access/browse_thread/thread/d7e676e3f179e992/180a99b7ad2252a9?lnk=gst&q=nathalie+lebas&rnum=3#180a99b7ad2252a9
et notamment :
http://groups.google.fr/group/microsoft.public.fr.access/msg/ea24dadf742e1a2a
La suggestion de mettre les 2 bases dans le même dossier sur le serveur ne
valait que pour tester la vitesse, puisque Nathalie a essayé de mettre la
frontale sur le poste client et s'est retrouvé avec des lenteurs plus
importantes qu'une seule base sur le serveur.
Toutefois, j'ai plusieurs bases (de moindre importance) dont le code et les
données sont placés uniquement sur un serveur (pour des raisons
"historiques") et cela fonctionne depuis plusieurs années sans problème et
avec une vitesse honorable. Le transfert des objets ne se fait qu'une seule
fois lors de la première utilisation dans la session.
Je redoute plutôt la corruption de la base "code" qui bloquerait tout le
monde. Ce qui n'est pas le cas avec la frontale sur poste client.
Mais, pour revenir au problème de Nathalie (coucou !) et comme je lui ai
déjà dit, 510 formulaires, 940 requêtes et 270 états... me laissent songeuse
;-)
--
Tisane
Hello Pierre "3stone",| J'ai déjà évoqué ce problème avec Tisane il y a un moment car ma base
| grossie et j'aurrais souhaité deux bases.
Sauf pour une petite base locale, il faut toujours scinder une base Access
en frontale et dorsale. Et c'est absolument obligatoire lorsqu'il y a
plusieurs utilisateurs sumultanés !
[...]| Tisane m'avait suggéré de mettre les deux bases dans le même répertoire
du
| serveur mais je n'ai pas encore eu le temps de faire des essais avec
tous mes
| utilisateurs.
Non, la frontale doit se trouver sur le poste de l'utilisateur.
A défaut, les formulaires, états et autres objets doivent également
transiter par le réseau.
[...]
Nous sommes parfaitement d'accord. L'information est toujours déformée au
fil du temps...
http://groups.google.fr/group/microsoft.public.fr.access/browse_thread/thread/d7e676e3f179e992/180a99b7ad2252a9?lnk=gst&q=nathalie+lebas&rnum=3#180a99b7ad2252a9
et notamment :
http://groups.google.fr/group/microsoft.public.fr.access/msg/ea24dadf742e1a2a
La suggestion de mettre les 2 bases dans le même dossier sur le serveur ne
valait que pour tester la vitesse, puisque Nathalie a essayé de mettre la
frontale sur le poste client et s'est retrouvé avec des lenteurs plus
importantes qu'une seule base sur le serveur.
Toutefois, j'ai plusieurs bases (de moindre importance) dont le code et les
données sont placés uniquement sur un serveur (pour des raisons
"historiques") et cela fonctionne depuis plusieurs années sans problème et
avec une vitesse honorable. Le transfert des objets ne se fait qu'une seule
fois lors de la première utilisation dans la session.
Je redoute plutôt la corruption de la base "code" qui bloquerait tout le
monde. Ce qui n'est pas le cas avec la frontale sur poste client.
Mais, pour revenir au problème de Nathalie (coucou !) et comme je lui ai
déjà dit, 510 formulaires, 940 requêtes et 270 états... me laissent songeuse
;-)
--
Tisane
Salut,
"Nathalie Lebas"
[...]
| Par contre le formulaire en
| question contient beaucoup d'onglets et de sous-formulaires, qui ne soit pas
| bien optimisé, là je suis d'accord avec toi.
Nous y voilà ;-)
Comme tu ne travaille pas dans tous les sous-formulaire en même temps,
tu peux soit les lier au moment du clic sur l'onglet, soit réduire au maximum
le nombre d'enregistrement rapatriés.
| Cet après-midi, j'ai tenté de me connecter sur cette base en liant les
| tables, c'est désastreux et je ne comprends pas pourquoi.
Cela n'était pas ainsi avant ?
|J'ai toujours
| développé avec 2 bases et les tables liées sans problème.
Ok !
| Depuis que je suis ici je n'y arrive pas et je ne localise pas le problème.
Que veux tu dire par "depuis que je suis ici" ?
PS: Raymond avait il y a un temps rédigé un article sur l'optimisation
tu devrais trouver cela sur sont site...
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Salut,
"Nathalie Lebas"
[...]
| Par contre le formulaire en
| question contient beaucoup d'onglets et de sous-formulaires, qui ne soit pas
| bien optimisé, là je suis d'accord avec toi.
Nous y voilà ;-)
Comme tu ne travaille pas dans tous les sous-formulaire en même temps,
tu peux soit les lier au moment du clic sur l'onglet, soit réduire au maximum
le nombre d'enregistrement rapatriés.
| Cet après-midi, j'ai tenté de me connecter sur cette base en liant les
| tables, c'est désastreux et je ne comprends pas pourquoi.
Cela n'était pas ainsi avant ?
|J'ai toujours
| développé avec 2 bases et les tables liées sans problème.
Ok !
| Depuis que je suis ici je n'y arrive pas et je ne localise pas le problème.
Que veux tu dire par "depuis que je suis ici" ?
PS: Raymond avait il y a un temps rédigé un article sur l'optimisation
tu devrais trouver cela sur sont site...
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Salut,
"Nathalie Lebas"
[...]
| Par contre le formulaire en
| question contient beaucoup d'onglets et de sous-formulaires, qui ne soit pas
| bien optimisé, là je suis d'accord avec toi.
Nous y voilà ;-)
Comme tu ne travaille pas dans tous les sous-formulaire en même temps,
tu peux soit les lier au moment du clic sur l'onglet, soit réduire au maximum
le nombre d'enregistrement rapatriés.
| Cet après-midi, j'ai tenté de me connecter sur cette base en liant les
| tables, c'est désastreux et je ne comprends pas pourquoi.
Cela n'était pas ainsi avant ?
|J'ai toujours
| développé avec 2 bases et les tables liées sans problème.
Ok !
| Depuis que je suis ici je n'y arrive pas et je ne localise pas le problème.
Que veux tu dire par "depuis que je suis ici" ?
PS: Raymond avait il y a un temps rédigé un article sur l'optimisation
tu devrais trouver cela sur sont site...
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)