Discussion :

[Hanyf]

Bonjour,
Dans MS Access lorsque j'ouvre un formulaire contenant des sous-formulaires qui contiennent des contrôles onglets, qui contiennent, évidement, aussi d'autres types de contrôles; et ceci que se soit en mode design ou à l'exécution , j'ai un message d'erreur N° 28 : "Espace pile insuffisant" de l'application.

Serait-il possible d'agir sur certains paramètres de MS Access et/ou l'OS (Windows 7 64 bits), pour augmenter la taille de l'espace pile alloué par le système à l'application ?
Car cela se produit aussi pour des procédures complexes et/ou récursives. En fait , je voudrais savoir s'il est possible d'augmenter la profondeur d’appels de la pile ?

Message d'erreur:


Merci pour toutes les suggestions de solutions...

[loufab]

Bonjour,

Avant de tripoter au système tu as essayé les manips de réparation habituelles ?

Compactage
et
Decomp/comp
cf mon blog http://blogaccess.free.fr/?p=75

J'ai rarement vu des dépassements de piles en mode création. En principe quand on arrive à la limite du nombre de contrôle par formulaire ce n'est pas un dépassement de pile qu'on obtient.

Côté code, ne pas fermer les objets qu'on utilise peut avoir ces conséquences.

Elle est vraiment énorme cette application ?

Cordialement,

[Hanyf]

Je te remercie Loufab pour ta suggestion, mais je l'ai déjà tenté sans succès.
En effet j'ai utilisé, pour ma base qui est sous MS Access 2010, la décompilation et le compactage avec les 2 commandes suivantes:

C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE /decompile
C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE /compact
Evidemment après, j'ai recompilé le projet VBA, avec aucune erreur; et j'ai même recompacter Access depuis son menu intégré.

Il est vrai qu'après ce traitement Access s'ouvre et charge mon application plus rapidement.
Mais quand je reprend le design des formulaires et des sous-formulaires, subitement j'ai Access qui plante, en me le signifiant par cet écran:

Avec la fermeture de l'application et la génération du fichier .laccdb résultant.

A propos du système, je te rassure, je ne risque pas de le "tripoter", car je code sans avoir les droits admin, ni d'accéder à la base de registre, par la commande REGEDIT.
Pour ce qui est de la machine, je développe sur un laptop (sic), donc avec un disque dur qui tourne moins vite que sur un desk (5200 tr/mn contre 7200 voir 10 000 tr/mn).
Donc je pense que le souci pourrait provenir d'un manque de ressources (on revient au problème de RAM du début), du à la pagination excessive, ce qui accroit le fichier d'échange et donc ralentit le système, qui en conséquence pénalise Access.

Peut-être, une solution serait-elle de scinder l'application en plusieurs fichiers .accdb et/ou .accde ?
Une autre serait de transformer l'application en Service pour obliger le système à lui allouer plus de ressources ?
Qu'en penses-tu ?

[loufab]

Si après le decomp/comp tu as ce message c'est qu'il y a un vrai problème de structure de fichier.

Voici ce que tu peux faire :
1) créer un fichier vierge et y transférer tous les objets "saints".
2) exporter/importer en mode texte les objets qui posent problème.

Export :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

application.SaveAsText acForm, "formulaire1", "d:\formulaire1.frm"

import :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Application.LoadFromText acForm, "formulaire1", "d:\formulaire1.frm"

Sinon créer des bibliothèques ne peut pas faire de mal. Cependant attention ! Certaines commandes restes locales à la bibliothèque et certaines instructions qui doivent être légèrement modifiée lorsqu'elles sont appelés depuis des fichiers différents.
Je ne me rappelle plus exactement lesquelles.

Sinon je ne pense pas qu'une vitesse disque ou qu'un manque de ram soit le problème.

Cordialement,

[Hanyf]

Merci pour toutes ces indications; Il faut juste rappeler que les méthodes SaveAsText() et LoadFromText() sont des membres cachés.
En effet pour pouvoir bénéficier du "Complément automatique des instructions" et de l'IntelliSense de VBE, il convient d'afficher, depuis l'explorateur d'objets (Touche: [F2], dans VBE)
ces membres cachés de l'objet Application de la bibliothèque Access :



Après cela on s'aperçoit que VBE retrouve ses automatismes, en nous proposant les membres qui deviennent visibles ( quoi que estompés ):



D'ailleurs, il y aurai beaucoup à dire sur ces membres cachés, que l'on connaît bien dans le milieu des développeurs sous la notion de "Fonctionnalité non documentée", pour les curieux:
je recommande particulièrement :
https://blogs.msdn.microsoft.com/thi...-boring-again/
Et, également, une partie de ton article Loufab : http://loufab.developpez.com/tutorie...numVBA/#LIII-B

Ensuite j'ai pu donc implémenter ces 2 méthodes et coder comme d'habitude et j'ai réussi, effectivement à exporter les formulaires et les modules, par contre pour les tables ça ne fonctionne pas;
En effet VBA /Access génère l'erreur N° 2487 :



Mais heureusement pour les tables j'utilise JMerise http://www.jfreesoft.com/JMerise/
qui me sort le MCD le MLD et le MPD et donc le code SQL des tables que j'enregistre dans des requêtes SQL DDL (Requêtes création de table, en mode SQL, dans Access).
C'est l'occasion de remercier le développeur de JMerise en la personne de M.MESSOUCI.

J'ai quand même pu récupérer une grosse partie de l'application.
Mais pour lever tous doute je vais réinstaller Access et libérer un peu de RAM et jouer sur la mémoire virtuelle.
En espérant que tout rentrera dans l'ordre.

Bien cordialement.
En encore merci à tous les contributeurs pour leur aide.

[loufab]

En effet il y a beaucoup de membres cachés intéressants, il y a aussi une bibliothèque cachée très sympathique : la Wizhook.

[Hanyf]

Donc après avoir pu récupérer une grosse partie des objets de l'application métier, j'ai réinstallé MS Access 32 bits avec un configuration plus puissante:

• OS: 64 bits
• Processeur: Xeon,
• RAM physique: 8 Go
• Espace disque disponible: 200 Go
• Architecture : frontale/ dorsale.

Et depuis, la conception des formulaires avec leurs sous formulaires et les contrôles onglets fonctionne normalement.
Le code VBA recompile à nouveau, sans soucis.
Il n' y a plus de problème de débordement de pile.

Merci Loufab pour tes conseils qui on été très utiles