Salut,
 
Dans le code suivant :
 

 
Je me demandais si :

 
était absolument nécessaire! Bien sur, je parle d'un point de vue optimisation (vitesse d'exécution et données en mémoire)
Est ce que ca sert vraiemnt à quelque chose de mettre ces lignes (à part pour la propreté du code?) ou de toute maniere, une fois la procédure terminée, les objects seront éliminés de la mémoire?
 
A vrai dire, je me pose pas mal de questions sur VBA et Access depuis quelques temps, mais je ne trouve pas de lien sur MSDN ou ils parlent d'optimisation pour VBA/Access.
 
Yoyo*

Point de vue optimisation, il est toujours intéressant de faire soi-même des opérations qui sont prises en charge par VB implicitement.
 
Donc oui, détruis toujours proprement tes objets et tu limiteras le nombre de problèmes potentiels
 
il faut savoir que VB fait bien son travail dans beaucoup de cas, mais "seulement" beaucoup.  Dans les autres cas, au choix ça plante, ou le programme reste chargé en mémoire alors qu'on croit l'avoir quitté.

D'accord, donc, la conclusion, c'est que ca peut etre plus rapide si je le fais à la main, mais au bout du compte, "normalement", il n'y aura pas de perte en mémoire si je ne le fais pas?

normalement, tout est relatif avec VB tu sais

Normalement, VB le fait lui-même, mais lorsque le programme s'arrête (pas quand la fonction est finie)
 
Donc mettons que tu entres 20 000 fois de suite dans une fonction créant un RS, si tu le détruit pas... Bah tu tas swapper sévère. Mais au final, quand tu vas quitter le programme, tu vas revenir à une utilisation normale.
 
PS: niveau perfs, les lignes "rs.close()" et set "rs = nothing" (idem avec cnx) sont instantannées. C'est pas VB qui le gère, mais ADO lui-même, et il le fera en // donc aucune différence d'un point de vue vitesse d'éxécution du code.

 
Oups, j'ai oublié de préciser que mes RecodSet sont des DAO ! Mais bon, je pense que c'est plus ou moins la meme chose
 
Conclusion, j'ai intéret à etre propre, car si mon appli est ouverte pendant 24h, alors de la "merde" risque de s'accumuler en mémoire? J'ai aussi intéret à gérer tout ca dans mes gestions d'erreur, si une erreur survient, je suppose?

Pas si c'est 24h, tu t'en bat les ***** parcequ'il va y avoir des timeout (pas d'activité = timeout) donc les objets vont s'auto-killer tout seuls.
 
y'a juste les objets CNX qui vont rester ouverts et valides (mais avec une connection fermée) mais de toute façon, faut pas en ouvrir 50, tu utilises tout le temps le même...

 
Je n'utilise pas ADO, donc, pas de probleme concernant les Objects "CNX".
 
LEs timeouts marchent commznt? Ca veut dire que Access (ou le moteur VBA?), de temps en temps, apssent en revue les objets et regardent quand ils ont éé utilisés la dernbiere fois, et si ca fait "longtemps", alors il kille?

Il kill pas les rs, mais les close, donc libère la mémoire qu'il occupent (du moins, l'intégralité des données qu'ils avaient retourné)

 
D'accord, je saisis, donc, les rs ne sont pas "libérés" à la fin de la procédure, mais plus tard seulement (TimeOut)

Ca démends, mais oui, ça arrive souvent qu'en sortie de procédure ils restent instancié, chais pas pourquoi, des fois VB déclare ses variables en globale sans qu'on lui demande rien.

Mais comment tu sais tout ça toi? Tu as un moyen de voir ce qui reste en mémoire parmi tout ce que crée VB(A)?
 
Sinon, connaitrais tu des pages web expliquant comment optimiser son code, genre utiliser des Long à la place de Int, ne pas utiliser de Variant quand c'est possible, etc...
 
Je suis assez friand de ce genre d'infos ! Ca ne mange pas de pain, et c'est bon psychologiquement de savoir qu'on ne perd pas de temps à cause de trucs "débiles"