¿Es necesario cerrar un objeto Adodb.recordset antes de establecerlo en nada?

Dim rs as ADODB.Recordset 
set rs = ReturnARecordset 'assume ReturnARecordset does just that... 

'do something with rs 

rs.Close 
set rs = Nothing

¿Es necesario llamar a rs.Close antes de configurarlo a nada?¿Es necesario cerrar un objeto Adodb.recordset antes de establecerlo en nada?

Editar: Tenemos una conexión global que mantenemos abierta durante la aplicación y todos los objetos del conjunto de registros utilizan esta misma conexión. Veo dos respuestas a continuación sobre la necesidad de cerrar conjuntos de registros para garantizar que las conexiones no se dejen abiertas. Para mí, eso suena como una gran cantidad de conversaciones tontas porque las conexiones se controlan con objetos de conexión, no con objetos de conjunto de registros, ¿no? Pero, por favor, avíseme si me falta algo aquí ...

Fuente

2011-12-05 Brandon Moore

La única razón por la que llama al Close explícitamente es cuando no está seguro de si el conjunto de registros está referenciado desde otro lugar en su proyecto, generalmente como resultado de una codificación descuidada.

Dim rs as ADODB.Recordset 
Set rs = ReturnARecordset 
... 
MyControl.ObscureMethod rs 
... 
Set rs = Nothing

última línea se supone que debe terminar la instancia de registros sin llamar Close explícitamente, a menos que MyControl es la celebración de una referencia adicional y evitando así la normalidad desmontaje. Llamar al Close en rs se asegurará de que MyControl no pueda usar su referencia para nada útil, mientras tanto, se encienda en llamas.

Fuente

2011-12-05 21:37:30 wqw

Mis pensamientos exactamente. Intento principalmente averiguar si hay una razón válida para llamar al método Close en las variables del conjunto de registros que son privadas para la función en la que se crearon y salir rápidamente del alcance. –

Llamar 'Close', establecer explícitamente * local * referencias a' Nothing' son partes de la misma programación de Cargo Cult que el cuarto de baño de Internet del código está lleno. Use el sentido común, lo mejor sería probar las fugas en su entorno particular. – wqw

Sí, nunca me pongo a nada cuando sé que está a punto de quedar fuera del alcance de todos modos. Pero no quería escuchar respuestas múltiples sobre la importancia de ponerlo a cero cuando no era eso de lo que se trataba mi pregunta, así que puse la línea para evitar esos comentarios :) –

Sí, esto hace más que simplemente forzar una recolección de basura, también le dice al servidor que la conexión se está terminando, esto evita tener múltiples conexiones abiertas huérfanas (eventualmente pasarán el tiempo de espera por sí mismos), pero su mejor práctica siempre es cerrarlos.

Esto es especialmente evidente cuando ADODB utiliza una conexión remota en lugar de una conexión local.

Fuente

2011-12-05 01:49:18

Eso no tiene sentido. Recordset.Open toma un objeto de conexión como parámetro y cerrar el conjunto de registros no cierra la conexión. Nuestra aplicación tiene un único objeto de conexión que permanece abierto mientras dure la aplicación y todas las consultas usan este objeto. Entonces, con eso en mente, ¿hay alguna otra razón para cerrar el conjunto de registros? Supongo que cuando el recuento de referencias del conjunto de registros llegue a 0, se encargará de todo lo que llame a Cerrar en su destructor, pero no estoy seguro, así que es por eso que estaba preguntando. –

Es decir, ¿hay alguna otra razón para cerrar un conjunto de registros cuando se establecerá de inmediato en nada después (ya sea explícitamente o saliéndose del alcance) –

Puede encontrarse con ODBC u OLEDB cuestiones de fondo común, que mantienen una conexión abierta y atar una ranura de la piscina:

Las causas comunes de la fluencia de conexión incluyen:

La conexión ADO y objetos de registros se no realmente cerrado. Si no los cierra de forma explícita, no se liberarán en el grupo. Esta es probablemente la causa más frecuente de creep de conexión.

Un objeto ADO que ha creado (especialmente un objeto Connection) no se ha liberado de forma explícita. Liberar explícitamente los objetos que creas es una buena práctica de programación. Si asigna memoria, libérela. Dependiendo del idioma que esté utilizando, dejar que una variable salga del alcance puede o no dar como resultado que se lance.

Ver Pooling in the Microsoft Data Access Components

Y si hay alguna posibilidad de .Net interoperabilidad implicados tener cuidado: hay un montón de advertencias acerca de problemas causados debido al objeto manera perezosa COM (u objeto contenida) la liberación se produce bajo. La recolección de basura de Net.

Fuente

2011-12-05 21:48:52 Bob77

Por favor, mira mi edición y hazmelo saber si me falta algo aquí ... –

Pooling no es un problema por lo que sé cuando un Recordset no se abrió con su propia conexión. – Bob77

Ok, eso tiene sentido. Solo he estado trabajando con conjuntos de registros a los que se les ha pasado un objeto de conexión y honestamente ni siquiera recuerdo que podrías abrirlos sin hacerlo. Gracias. –

¿Es necesario cerrar un objeto Adodb.recordset antes de establecerlo en nada?

Respuesta

Cuestiones relacionadas