Dans une forme MS-Access, j'ai le code suivant attaché à un événement:MS Access: .Close obligatoire après .RecordSetClone?
Dim frm As Form, rs As Recordset
Set rs = Me.RecordsetClone
'do some stuff with rs
'
rs.Close
Set rs = Nothing
Set frm = Nothing
Ma question est: est le rs.Close nécessaire? Est-il même bon (effets secondaires non désirés?)
Non, la fermeture n'est pas nécessaire, et la règle est simple si votre code n'a pas ouvert le reocrdset, alors vous ne voulez pas le fermer. Donc, vous voulez seulement/devez fermer les choses que vous avez opérées. Par conséquent, vous utilisez un jeu d'enregistrements intégré existant et vous n'avez pas ouvert ce jeu d'enregistrements. Mettre les deux à rien comme vous n'avez pas besoin, mais il peut rester en place, et montre clairement vos intentions que vous avez faites avec les objets.
Je ne pense pas que le monde se terminerait mais c'est toujours une bonne pratique de fermer ce que vous ouvrez.
L'accès à un problème où, si vous n'aviez pas disposé d'un objet, il ne s'arrêtait pas, mais au contraire il se réduisait à la barre des tâches et vous deviez tuer la tâche. Cependant, lorsque vous mettez l'objet à zéro, cela ne vous affectera pas
Ma préoccupation dans la question est que nous parlons ici d'un * clone *, que je comprends comme un pointeur vers un autre objet préexistant. –
Mais il ne l'a pas ouvert - le RecordsetClone du formulaire existe déjà. –
Vous devez définir votre variable de jeu d'enregistrements comme 'rs As DAO.Recordset'. Autrement dit, si vous allez le déclarer du tout. Il n'y a presque jamais de cas où cela soit nécessaire lorsqu'on travaille avec RecordsetClone. Au lieu de cela, utilisez un bloc WITH/END WITH, c'est-à-dire "With Me.RecordsetClone". –
@David: le With est une bonne idée. Je ne spécifie jamais la partie DAO car je ne référence jamais ADO, mais vous avez probablement raison et un jour je vais payer pour cela: -/ –
En le spécifiant, vous faites que le processus de compilation nécessite moins de résolution des objets implicites dans le espace de nommage. Bien que je n'ai jamais vu VBA se tromper avec seulement une référence DAO, je préfère dire à VBA ce qu'il faut regarder pour ne pas avoir à "s'inquiéter" à ce sujet. C'est aussi un meilleur codage - gardez à l'esprit que l'un des buts du code est d'informer un programmeur de ce qui se passe (pas seulement le compilateur), et spécifier DAO dans tous les cas le rend clair dans tous les cas. –