Encore moi ! Un petit problème, le dernier sûrement pour cet été : dans mon appli (VB6), je lance une boucle qui ouvre un état access, l'imprime puis le referme. Le souci, c'est que des processus Access restent ouverts et comme ça en lance beaucoup, ça finit par saturer la mémoire.
 
Voilà comment l'état est normalement refermé :

 
sachant qu'il était ouvert sans aperçu. Le code d'ouverture est un peu compliqué, enfin je l'ai repris dans ce qui existait et je me dis que peut être y'a des trucs inutiles dedans mais comme ça marchait je n'ai pas voulu courir de risque, j'avais assez de boulot    
 
Donc ouverture, au cas où ça joue :
 

 
Vala, si vous avez une idée de pourquoi le processus ne dégage pas de la mémoire, tant mieux !

Si tu empiles les ouvertures d'états avec le paramètre acViewPreview, je ne sais pas comment ça se comporte en mode OLE Automation (=la technique que tu utilises en faisant Set truc = New Access.Application).
Surtout que tu caches Access (MesEtats.Visble = False).
 
Dans l'exemple que tu montres, tu ouvres deux fois l'état et tu ne le fermes qu'une fois. Mais je suppose que c'est juste pour l'exemple.
Ça peut venir de là, mais SGDG.

Ben non ça n'est pas que pour l'exemple, c'est toujours comme ça. La preview n'est peut être pas utile mais je n'ose pas l'enlever, je ne me souviens pas si j'avais essayé ou pas.  
Voilà de quoi occuper mes 2 derniers jours de contrat....

Je dois faire les 2 ouvertures (j'ai testé, en fait c'est qu'il y a un remplissage de champs et si on ne fait pas le acviewpreview, même si on ne veut pas visualiser l'aperçu, ça ne les remplit pas.)
La fermeture doit pourtant fermer tout ?!? Je vais me faire jeter je pense, si je fais 2 fermetures : pour la 2e il va dire qu'il ne sait pas ce qui est dans l'objet MesEtats...
 
Edit : je confirme, il jette si on essaie de fermer 2 fois.
 
De même il y a 2 ouvertures de MesEtats (le Set et le OpenCurrentDatabase), mais pour moi, ça écrase si on rouvre sur le même objet, non ?
 
 

J'ai testé ta méthode ; elle semble fonctionner en théorie (j'ai pas empilé les appels).
Une meilleure solution serait de remplir la valeur de texte18 par du code VBA dans l'état lui-même (à l'ouverture de l'état).
Tu n'aurais alors qu'un appel à faire pour lancer l'état.
 
Sinon, revenons en aux fondamentaux.
J'ai compris qu'un processus Access saturait ta mémoire, mais je voudrais que tu décrives le symptôme et que tu cites les messages d'erreur qui t'amènent à penser cela ?
 

En fait, cette boucle est parcourue pas mal de fois, enfin hier on devait en lancer 90. Et après avoir eu un message d'erreur du style "Mémoire insuffisante [...] quittez les applications actives et réessayez", on a surveillé avec le gestionnaire de tâches. Pour chaque passage dans la boucle, un processus Access était ajouté, mais pas supprimé.
Mon chef a fini par trouver en bidouillant, un code qui refermait les processus Access au fur et à mesure. Je suis sceptique sur les "mesetats.quit" qui ont juste été déplacés, par contre le gros changement c'est qu'on ne fait plus du tout  "MesEtats.OpenCurrentDatabase mydb, False"  ni "MesEtats.CloseCurrentDatabase".
 
Moi, j'aurais pas osé virer ça, mais visiblement c'était superflu puisque ça a l'air d'avoir fonctionné. Et c'est mieux parce que dans les prochains mois il y aura bien plus de 90 états à lancer    
Si j'ai le temps d'ici demain soir je tenterai ton remplissage du texte18 dans l'état, si ça peut alléger encore un peu la chose...
Merci encore.