Déterioration performance formulaire

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)

Bonjour,
Merci de me répondre.
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. C'est
pour cela que je travaille avec une seule base par obligation.
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.
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.
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.
Aujourd'hui, je m'inquiète de voir qu'un formulaire puisse se dégrader au
fil du temps et pas les autres.
Qu'en penses-tu ?
A +
--
Nathalie

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)

Bonsoir Pierre,

Lorsque j'ai conçu la base sur papier, comme tu dis, je l'ai optimisée et
normalisée. Donc je ne pense pas que ce soit le soucis. Elle fonctionne
maintenant depuis deux ans. Certaines tables contiennent beaucoup
d'enregistrements, une en particulier 172000. 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.
Quand je dis que le formulaire se déteriore, je pense bien sûr que ce n'est
pas lui puisque je n'intervient pas sur lui pour résoudre le problème.
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. J'ai toujours
développé avec 2 bases et les tables liées sans problème. Depuis que je suis
ici je n'y arrive pas et je ne localise pas le problème.
A+
--
Nathalie

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"
[...]
| 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)

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

Bonjour Tisane,

"Tisane"
[...]
| Nous sommes parfaitement d'accord. L'information est toujours déformée au
| fil du temps...

Je n'en ai pas douté un instant...

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)

Bonjour Tisane,
Excuses-moi je n'ai pas voulu déformer ce que tu m'as écris. Je pense bien
réaliser ce test en mettant dans le même répertoire la base avec le code et
celle avec les données. Par contre, pour aller au bout du test, il me faut
des utilisateurs. Je pense donc réaliser ce test en août où nous serons de
permanence une semaine avec 3 utilisateurs.
--
Nathalie

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

Bonjour Pierre,
Je m'explique sur ce que j'ai écris :
"Depuis que je suis ici je n'y arrive pas et je ne localise pas le problème."
Je suis dans cette société depuis un peu plus de deux ans. Avant, je
pratiquais Access dans d'autres sociétés et je développais avec deux bases
comme nous en avons parlé, sans problème.
Lorsque je suis arrivé ici, j'ai commencé à travailler avec deux bases et
lorsque je les ai mises en exploitation sur 4, 5 utilisateurs, ceux-ci
étaient bloqués ou les temps de réponse était désastreux. A l'époque, il
s'agissait d'une toute petite base avec quelques formulaires (rien à voir
avec maintenant). Je n'ai pas compris le problème à l'époque et n'ai pas
trouvé d'aide en locale. J'ai tenté en créant une seule base et en la mettant
sur le serveur et là pas de problème. J'ai donc continué ainsi.
Cependant je me pose souvent ce problème surtout en voyant mes deux bases
grossir. Je sais (en lisant ce forum) que le fait de partager en deux bases
lorsque l'on travaille en réseau est important.
Depuis plusieurs mois, je cherche ici en locale (car je manque de temps) une
formation d'optimisation de base et de développement. Mais nous sommes dans
une petite ville de province et ce n'est pas simple.
Le seul conseil que l'on me donne est de passer sur SQL Server, le problème
est que cela demande du temps que je n'ai pas. Je préfèrerais pouvoir
optimiser ma base actuelle.
Concernant le formulaire qui me pose problème aujourd'hui, je vais le
diviser en deux et ainsi partager entre deux formulaires les onglets, dans un
premier temps.
A+

--
Nathalie

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)

Bonjour,

"Nathalie Lebas"
[...]
| J'ai tenté en créant une seule base et en la mettant
| sur le serveur et là pas de problème. J'ai donc continué ainsi.

Mettre la base (frontale + dorsale) sur le serveur n'est jamais une bonne solution
(en dehors de tests comme indiqué par Tisane)
Perso (en dehors des toutes petites application mono-poste), je scinde toujours
mes bases en frontale-dorsale, même lorsque les deux se trouvent sur un seul
et même poste. Cela apporte une solidité incroyable à la base.
Même des dizaines de sorties "sauvages" par des utilisateurs peu scrupuleux
et sans formation, n'ont eu raison d'une seule de mes bases - corruption zéro !


| Cependant je me pose souvent ce problème surtout en voyant mes deux bases
| grossir. Je sais (en lisant ce forum) que le fait de partager en deux bases
| lorsque l'on travaille en réseau est important.

Il est normal qu'une base que l'on utilise grossisse.
Le tout est de voir si c'est en rapport avec les saisies qui sont réalisées.
Même les interrogations suivis de suppressions font grossir la base. Car les
suppression doivent êtrent suivies d'un compactage pour avoir de l'effet.

Une base qui gonfle sans rapport avec les saisies serait un signe de corruption.


| Depuis plusieurs mois, je cherche ici en locale (car je manque de temps) une
| formation d'optimisation de base et de développement. Mais nous sommes dans
| une petite ville de province et ce n'est pas simple.
| Le seul conseil que l'on me donne est de passer sur SQL Server, le problème
| est que cela demande du temps que je n'ai pas. Je préfèrerais pouvoir
| optimiser ma base actuelle.


Tu ne trouveras pas de "formation d'optimisation", ville de province ou non.

Ce qui défini le choix de la base de données est la destination et l'usage...
Si, au regard de la quantité de données, le nombre d'utilisateurs simultanés,
et le trafic engendré, une base Access suffit - il est idiot de répondre :
"passe à SQL Serveur" !
C'est comme si on avait un petit transport à effectuer, mais que l'on roule
avec l'embrayage qui patine, le frein à main serré, les pneus dégonflés
et que l'on te dise : prends un camion ;-))

Soit Access convient; est à la limite; ou ne convient pas !
Mais il faut savoir pourquoi, dans chacun des cas.

| Concernant le formulaire qui me pose problème aujourd'hui, je vais le
| diviser en deux et ainsi partager entre deux formulaires les onglets, dans un
| premier temps.

Cela indiquerait que ces sous formulaire n'avaient rien à faire là...

Les sous formulaire ne doivent se trouver dans un même formulaire principal
que si la saisie doit se faire à tour de rôle dans tous ces sous formulaire.
Autrement dit : si dans le formulaire principal, tu passe d'un enregistrement
au suivant et que tu n'utilise lors d'un traitement x qu'un seul et même sous
formulaires... les autres sous-form n'ont rien à faire là - sauf à bloquer la base
et à ralentir tout le monde.

Une règle intrangisante à respercter :
N'ouvrir que le recordset nécessaire à l'édition prévue. Ne rammener que les
données absolument obligatoires - rien de plus !
Ne pas ouvrir en dynamique pour une simple consultation. Cela est d'autant plus
important lorsque que l'on utilise beaucoup de tables secondaires (annexes)
et qui risquent d'être bloquantes.

Tout cela est à vérifier et à maitriser lors de la conception. Les modifications
ultérieures demandent parfois à revoir des pans entiers d'une base.

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)