En panne dans une application Access 2003
Fermé
Philippe (FSC)
-
14 févr. 2008 à 01:41
cchristian Messages postés 921 Date d'inscription lundi 21 janvier 2008 Statut Membre Dernière intervention 6 mars 2012 - 11 mars 2008 à 15:32
cchristian Messages postés 921 Date d'inscription lundi 21 janvier 2008 Statut Membre Dernière intervention 6 mars 2012 - 11 mars 2008 à 15:32
A voir également:
- En panne dans une application Access 2003
- Application mobile - Guide
- Désinstaller une application sur pc - Guide
- Application gps sans internet - Guide
- Télécharger application tensiomètre gratuit - Télécharger - Vie quotidienne
- Comment supprimer une application préinstallée sur android - Guide
9 réponses
cchristian
Messages postés
921
Date d'inscription
lundi 21 janvier 2008
Statut
Membre
Dernière intervention
6 mars 2012
131
15 févr. 2008 à 21:02
15 févr. 2008 à 21:02
Je ne connais pas Access 2003, mais le problème rencontré est assez classique.
Dans le cadre de ta formation à Access 2003 tu as dû vraisemblablement être sensibilisé sur les notions d'optimisation et surtout celle relative à la réorganisation périodique des fichiers et des bases de données. Je pense que c'est de ce côté qu'il faut regarder.
Dans le cadre de ta formation à Access 2003 tu as dû vraisemblablement être sensibilisé sur les notions d'optimisation et surtout celle relative à la réorganisation périodique des fichiers et des bases de données. Je pense que c'est de ce côté qu'il faut regarder.
LatelyGeek
Messages postés
1758
Date d'inscription
vendredi 4 janvier 2008
Statut
Membre
Dernière intervention
5 janvier 2023
550
15 févr. 2008 à 21:58
15 févr. 2008 à 21:58
Compactes-tu ta base à intervalles réguliers, par exemple? C'est simplissime (Outils - Utilitaires de base de données), déjà ça devrait pas mal réduire la taille de ta base et donc augmenter sa rapidité. C'est le principe de la défragmentation...
Réponse à LatelyGeek
Merci pour ta réponse. Ce n'est pas la bonne piste. La base de données est déjà régullièrement compactée. Je maîtrise cet aspect depuis le tout début du travail. Et Malgré cela ... la taille du fichier Access est de 1,1 Gb. J'anticipe même 1,3 Gb si je poursuis ce développement. Sans compter qu'il y a très peu de données utilisateurs dans les tables du fichier ... En fait, je pense que j'ai une manière de programmer qui est probablement "trop graphique" pour les possibilités de ACCESS (ou par rapport à d'autre programmeurs). La différence viendrait peut-être de là.
Voici la piste que je creuse en ce moment :
J'ai testé le plus gros des fichier "corrompus" sur 3, 4 autres PCs (ex. cybercafé). "Il semble" (je mets au conditionnel) que les PC avec >500 Ko de RAM (comme mon portable actuel) échoue à le charger, et ceux à partir de >1.000 ko de RAM accepterait au moins de le charger. Cela reste lent, mais peut-être acceptable pour les besoins immédiats. Je réfléchit donc à acheter tout simplement un nouveau portable type DUO dernier cri, rien que pour utiliser ce fichier. Je verrai bien.
Bien à toi,
Philippe (FSC)
Merci pour ta réponse. Ce n'est pas la bonne piste. La base de données est déjà régullièrement compactée. Je maîtrise cet aspect depuis le tout début du travail. Et Malgré cela ... la taille du fichier Access est de 1,1 Gb. J'anticipe même 1,3 Gb si je poursuis ce développement. Sans compter qu'il y a très peu de données utilisateurs dans les tables du fichier ... En fait, je pense que j'ai une manière de programmer qui est probablement "trop graphique" pour les possibilités de ACCESS (ou par rapport à d'autre programmeurs). La différence viendrait peut-être de là.
Voici la piste que je creuse en ce moment :
J'ai testé le plus gros des fichier "corrompus" sur 3, 4 autres PCs (ex. cybercafé). "Il semble" (je mets au conditionnel) que les PC avec >500 Ko de RAM (comme mon portable actuel) échoue à le charger, et ceux à partir de >1.000 ko de RAM accepterait au moins de le charger. Cela reste lent, mais peut-être acceptable pour les besoins immédiats. Je réfléchit donc à acheter tout simplement un nouveau portable type DUO dernier cri, rien que pour utiliser ce fichier. Je verrai bien.
Bien à toi,
Philippe (FSC)
LatelyGeek
Messages postés
1758
Date d'inscription
vendredi 4 janvier 2008
Statut
Membre
Dernière intervention
5 janvier 2023
550
17 févr. 2008 à 13:26
17 févr. 2008 à 13:26
Qu'est ce que tu appelles "trop graphique?" Enfin, tu tiens sans doute ta solution, en augmentant les capacités de ton ordinateur... C'est vrai qu'Access est un peu gourmand de ce côté-là.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
A LatelyGeek
et Cchristian,
L'origine première du problème, je la situe dans la gestion par ACCESS 2003 des images, logos, et autres objets importés. Mes formulaires de base fonctionnent avec une image de 32 ko, plus un logo, une petite image d'imprimante... Les rapports, même chose. Les écrans d'accueil sont une émulation de page Web classique, image qui prend 300ko. Et bien, les 300ko deviennent 50 Mégabytes. La même chose pour tous les graphismes. Et, au bout du logiciel, les 1,3 Gbytes sont atteints, sans avoir mis la première donnée ... C'est ce qui m'inquiète !
Petite erreur dans mon test comparatif entre PC de puissance différente. Je dois le recommencer, car j'ai confondu le mode "Modification" et le simple mode "Ouvrir comme utilisateur" (formulaire), idem "Aperçu" (pour les état/rapports). J'ai fait les tests sur les autres PCs en mode "lecture utilisateur". Or, apparemment, mon PC ouvrent également sans difficulté. Les tables se remplissent également via mes formulaires instantanément. Mais C'est le mode "MODIFICATION" (la programmation des objets) que je dois retesté. C'est là que TOUT EST DEVENU SI LENT, inefficace sur le plan productif.
Provisoirement, je reste encore sur cette piste : Finaliser le plus urgent en Access, avec un plus gros PC.
Et ensuite, on m'a conseillé de faire tout reprogrammer en PHP ?
Votre avis ????
et Cchristian,
L'origine première du problème, je la situe dans la gestion par ACCESS 2003 des images, logos, et autres objets importés. Mes formulaires de base fonctionnent avec une image de 32 ko, plus un logo, une petite image d'imprimante... Les rapports, même chose. Les écrans d'accueil sont une émulation de page Web classique, image qui prend 300ko. Et bien, les 300ko deviennent 50 Mégabytes. La même chose pour tous les graphismes. Et, au bout du logiciel, les 1,3 Gbytes sont atteints, sans avoir mis la première donnée ... C'est ce qui m'inquiète !
Petite erreur dans mon test comparatif entre PC de puissance différente. Je dois le recommencer, car j'ai confondu le mode "Modification" et le simple mode "Ouvrir comme utilisateur" (formulaire), idem "Aperçu" (pour les état/rapports). J'ai fait les tests sur les autres PCs en mode "lecture utilisateur". Or, apparemment, mon PC ouvrent également sans difficulté. Les tables se remplissent également via mes formulaires instantanément. Mais C'est le mode "MODIFICATION" (la programmation des objets) que je dois retesté. C'est là que TOUT EST DEVENU SI LENT, inefficace sur le plan productif.
Provisoirement, je reste encore sur cette piste : Finaliser le plus urgent en Access, avec un plus gros PC.
Et ensuite, on m'a conseillé de faire tout reprogrammer en PHP ?
Votre avis ????
cchristian
Messages postés
921
Date d'inscription
lundi 21 janvier 2008
Statut
Membre
Dernière intervention
6 mars 2012
131
18 févr. 2008 à 02:13
18 févr. 2008 à 02:13
Bonsoir,
Pour ma part je ne connais pas ACCESS, il m'est donc impossible de t'aider, je le regrette.
Mais malgré tout et de manière générale, tout développement et technique de developpement confondus, il est assez rare de devoir redévelopper toute une application qui de surcroit sur le plan fonctionnel semble satisfaire les utilisateurs. En tout cas c'est dommage.
Toujours de manière générale, si ce n'est déjà fait car tu sembles l'évoquer, tu peux élaborer (ou parfaire) des tests progressifs de montée en charge tant au niveau de l'applicatif qu'à celui de la "volumètrie" de la base, ceci afin de mieux cerner le problème et surtout le "moment" où l'évènement "saturation" commence à se manifester. C'est un peu fastidieux mais il n'est pas rare que l'on découvre à la faveur de ces tests certaines choses auquelles on avait pas pensé. Un simple paramètre oublié ou méconnu ou en trop peu quelquefois faire une différence sensible.
P.S. Je viens de relire tes messages et intuitivement (et peut-être bêtement) je reste sur l'idée d'une mauvaise organisation et/ou d'une désorganisation de la base. En terme de réorganisation vous parlez de "compactage", n'existe-t-il pas d'autres utilitaires du type "réorganisation des indexes" ou du type "audit" de la base ?
Pour ma part je ne connais pas ACCESS, il m'est donc impossible de t'aider, je le regrette.
Mais malgré tout et de manière générale, tout développement et technique de developpement confondus, il est assez rare de devoir redévelopper toute une application qui de surcroit sur le plan fonctionnel semble satisfaire les utilisateurs. En tout cas c'est dommage.
Toujours de manière générale, si ce n'est déjà fait car tu sembles l'évoquer, tu peux élaborer (ou parfaire) des tests progressifs de montée en charge tant au niveau de l'applicatif qu'à celui de la "volumètrie" de la base, ceci afin de mieux cerner le problème et surtout le "moment" où l'évènement "saturation" commence à se manifester. C'est un peu fastidieux mais il n'est pas rare que l'on découvre à la faveur de ces tests certaines choses auquelles on avait pas pensé. Un simple paramètre oublié ou méconnu ou en trop peu quelquefois faire une différence sensible.
P.S. Je viens de relire tes messages et intuitivement (et peut-être bêtement) je reste sur l'idée d'une mauvaise organisation et/ou d'une désorganisation de la base. En terme de réorganisation vous parlez de "compactage", n'existe-t-il pas d'autres utilitaires du type "réorganisation des indexes" ou du type "audit" de la base ?
Merci Cchristian,
Oui, quelques outils d'audit existent bien.
Je les ai utilisés au début, mais sans
grands effets jusqu'à présent.
Je regarderai à nouveau.
En ce moment, comme j'arrive encore à programmer
malgré les difficultés, je finalise l'application au plus vite.
Je creuserai ensuite ton idée sur l'organisation des tables,
et l'indexation aussi des éléments entre eux.
Merci pour tout
Philippe (FSC)
Oui, quelques outils d'audit existent bien.
Je les ai utilisés au début, mais sans
grands effets jusqu'à présent.
Je regarderai à nouveau.
En ce moment, comme j'arrive encore à programmer
malgré les difficultés, je finalise l'application au plus vite.
Je creuserai ensuite ton idée sur l'organisation des tables,
et l'indexation aussi des éléments entre eux.
Merci pour tout
Philippe (FSC)
Comme j'ai entre-temps finalisé mon application, je vous fais part de la façon dont j’ai résolu mon problème : "En panne dans une application Access 2003" :
1) Tout d'abord, j'ai tout migré dans une version plus ancienne qui est "Access 2000". Le gain de taille est très conséquent. Mais paradoxalement, je n'observe aucune perte de fonctionnalité, même pour les rapports et formulaires qui présentent des graphiques relativement complexes.
2) Ensuite, j'ai séparé les données de l'application et l'application elle-même (écrans de démarrage, menus contextuels, formulaires, rapports à éditer, macros, etc.). De la sorte, l'apport en données des utilisateurs ne modifiera plus les performances des autres fichiers de l'application.
3) J'ai ensuite observé que le ralentissement de la performance intervenait sur mon PC dans les 2 cas suivants (tout deux réels dans mon cas) : le dépassement de 1,1 Gbytes pour la taille des fichiers "mdb" (Access) et une désorganisation du contenu des fichiers, consécutive à la programmation elle-même. Toute période de programmation (changement dans les objets, création, suppression, etc.) induit après un moment un ralentissement général dans le traitement du fichier (c'est-à-dire le fonctionnement de l'application). En ce sens, le précédent message de cchristian (Voir ci-haut) est déjà fondé.
4) Ensuite, j'ai constaté que ce sont les rapports à éditer qui pèsent le plus sur la taille des fichiers "mdb", bien plus que les formulaires. Et dans mon cas, il est donc possible de regrouper TOUS les formulaires (toute la navigation de l'utilisateur) en un seul fichier, et de le compléter par les rapports utilisés le plus fréquemment.
5) Ensuite, le compactage, c'était bien au début, cher LatelyGeek. Mais je ne l'utilise plus, car j'ai trouvé beaucoup mieux ...
6) En premier lieu, je crée un fichier "vide" contenant toutes les caractéristiques de l'application finale : paramètres du démarrage, sécurité, nom de l'application, image associée, etc.
7) Au terme de chaque phase de paramétrage, je duplique et je ré-alimente ce fichier "vide" avec tous les objets du fichier "mdb" que je viens de re-paramétrer dans le précédent fichier. La démarche est toute simple : "Menu Fichier / Données externes / Lier les tables" (pour les données des tables) et "Menu Fichier / Données externes / Importer" (pour les requêtes, macros, formulaires et rapports à éditer). Au terme de ceci, l'application est comme neuve, avec une réactivité maximale.
8) Pour adresser la taille des fichiers (second point de ralentissement), j'ai fais ce que beaucoup de fournisseurs de logiciel font déjà : ils scindent leur application en plusieurs modules. J'ai donc un modèle "général", complété par des fichiers "mdb" spécialisés dans l'un ou l'autre aspect de "utilisateur". Ces modules partagent évidemment les mêmes données. L'utilisateur peut ainsi fermer un module "X" et en ouvrir un autre module "Y" sans perdre le fil de ses donnnées. Il ne fera cela que pour éditer les quelques rapports plus spécialisés du module "Y". C'est mieux que de subir un ralentissement général de l'application.
Je remercie encore Cchristian et LatelyGeek pour leur aide précieuse.
Bien à vous !
1) Tout d'abord, j'ai tout migré dans une version plus ancienne qui est "Access 2000". Le gain de taille est très conséquent. Mais paradoxalement, je n'observe aucune perte de fonctionnalité, même pour les rapports et formulaires qui présentent des graphiques relativement complexes.
2) Ensuite, j'ai séparé les données de l'application et l'application elle-même (écrans de démarrage, menus contextuels, formulaires, rapports à éditer, macros, etc.). De la sorte, l'apport en données des utilisateurs ne modifiera plus les performances des autres fichiers de l'application.
3) J'ai ensuite observé que le ralentissement de la performance intervenait sur mon PC dans les 2 cas suivants (tout deux réels dans mon cas) : le dépassement de 1,1 Gbytes pour la taille des fichiers "mdb" (Access) et une désorganisation du contenu des fichiers, consécutive à la programmation elle-même. Toute période de programmation (changement dans les objets, création, suppression, etc.) induit après un moment un ralentissement général dans le traitement du fichier (c'est-à-dire le fonctionnement de l'application). En ce sens, le précédent message de cchristian (Voir ci-haut) est déjà fondé.
4) Ensuite, j'ai constaté que ce sont les rapports à éditer qui pèsent le plus sur la taille des fichiers "mdb", bien plus que les formulaires. Et dans mon cas, il est donc possible de regrouper TOUS les formulaires (toute la navigation de l'utilisateur) en un seul fichier, et de le compléter par les rapports utilisés le plus fréquemment.
5) Ensuite, le compactage, c'était bien au début, cher LatelyGeek. Mais je ne l'utilise plus, car j'ai trouvé beaucoup mieux ...
6) En premier lieu, je crée un fichier "vide" contenant toutes les caractéristiques de l'application finale : paramètres du démarrage, sécurité, nom de l'application, image associée, etc.
7) Au terme de chaque phase de paramétrage, je duplique et je ré-alimente ce fichier "vide" avec tous les objets du fichier "mdb" que je viens de re-paramétrer dans le précédent fichier. La démarche est toute simple : "Menu Fichier / Données externes / Lier les tables" (pour les données des tables) et "Menu Fichier / Données externes / Importer" (pour les requêtes, macros, formulaires et rapports à éditer). Au terme de ceci, l'application est comme neuve, avec une réactivité maximale.
8) Pour adresser la taille des fichiers (second point de ralentissement), j'ai fais ce que beaucoup de fournisseurs de logiciel font déjà : ils scindent leur application en plusieurs modules. J'ai donc un modèle "général", complété par des fichiers "mdb" spécialisés dans l'un ou l'autre aspect de "utilisateur". Ces modules partagent évidemment les mêmes données. L'utilisateur peut ainsi fermer un module "X" et en ouvrir un autre module "Y" sans perdre le fil de ses donnnées. Il ne fera cela que pour éditer les quelques rapports plus spécialisés du module "Y". C'est mieux que de subir un ralentissement général de l'application.
Je remercie encore Cchristian et LatelyGeek pour leur aide précieuse.
Bien à vous !
cchristian
Messages postés
921
Date d'inscription
lundi 21 janvier 2008
Statut
Membre
Dernière intervention
6 mars 2012
131
11 mars 2008 à 15:32
11 mars 2008 à 15:32
Bonjour,
Merci pour ce retour, je suis très heureux d'apprendre que tu as pù résoudre ce problème sensible et finaliser ton apllication sans avoir à la remettre en cause de manière fondamentale.
A bientôt, j'espère sur une prochaine discussion.
Merci pour ce retour, je suis très heureux d'apprendre que tu as pù résoudre ce problème sensible et finaliser ton apllication sans avoir à la remettre en cause de manière fondamentale.
A bientôt, j'espère sur une prochaine discussion.
