Cerrar Recordset y Connection

[FiNo]

Buenas, queria saber que problemas puede ocacionar el no cerrar los Connection y Recordset.

[Myakire]

independientemente de los problemas que causa dicha práctica. ¿Qué problema hay con cerrarlos?, son solo un par de lineas extra.

[FiNo]

Lo que pasa es que estoy haciendo unas modificaciones a unas páginas, las cuales no hice, y me encontre que en muchos casos no estan cerrados los recordset, entonces me surgio la duda que problema podria ocacionar esto.

[un_tio]

Iniciado por Myakire

independientemente de los problemas que causa dicha práctica. ¿Qué problema hay con cerrarlos?, son solo un par de lineas extra.

Pues yo sí encuentro problemas, cuando estoy con una página dinámica complicada, en la que a lo mejor el mismo recordset es utilizado en distintas partes del código, y este código está fragmentado en "If's..." (además de en funciones): ¿dónde lo cierras? Vale, al final del todo, "donde toque cerrarlo"; pues ponte tú a buscar el final de cada parte y a cerrar únicamente los recordset que hayas abierto (porque si intentas cerrar uno que no sea te dará error), para al final, que a lo mejor no hubiera pasado nada si no los hubieras cerrado, después de invertir un valioso tiempo en ello.

[u_goldman]

Bueno, pero si esto pasa, no tienes un buen diseno de tu codigo, en realidad no hay razon para "extraviar" procedimientos, pues si esto ocurre significa que no tienes control total sobre el flujo de tu aplicacion.

Generalmente esto se puede deber a mezclar en exceso la logica con el diseno.


Salu2,

[un_tio]

Sabía que alguien iba a decir algo así... Y no es el caso. Lo que es innegable es que a más líneas de código, por bien estructuradas que estén, más dificultad habrá para seguir por dónde van los RecordSet u otros objetos. Y deberás gastar un tiempo, mucho o poco, en buscarlos y ver dónde cerrarlos.

Por "diseño" entiendo que dices simplemente "aspecto gráfico del código fuente", y dices que he metido mucha más lógica que diseño (¿es así?).

No creo que el "diseño" y la lógica vayan reñidos, al contrario, más entendible será un código cuanto más lógico sea; es cierto que cuanta "más lógica" (más líneas), más complicado será mantener un "aspecto visual" claro, pero bueno, tampoco va uno a estar pendiente de darle forma para que quede bonito a un código ya muy largo conforme lo va haciendo (lo importante es que funcione). El problema está, repito, en que por buen diseño que pongas, si al final tienes 300 líneas de código... pues "no apetece" ponerte a repasarlo para ver dónde cerrar objetos, y máxime desconociendo su utilidad.

[u_goldman]

No un_tio, no me refería a que tu código se vea bonito o no, por diseño me refiero a los flujos de datos de tu sistema, lo que quise decir con un buen diseño, es precisamente lo contrario a lo que apuntas aquí:

Lo que es innegable es que a más líneas de código, por bien estructuradas que estén, más dificultad habrá para seguir por dónde van los RecordSet u otros objetos

En realidad un código bien estructurado no tiene por qué invitar a confusiones de este tipo, se trata nada mas de controlar las entradas/salidas de tu aplicación.

Código:

Function ObtenerLoqueQuieras()
  'abres tus objetos
  'haces tus procedimientos
  'Cierras y destruyes tus objetos utilizados para este procedimiento
  'quiero regresar un arreglo a partir de un recordset
End Function

llamo a mi funcion, que me regresa un arreglo
codigo HTML
imprimo mi arreglo, si quiero lo puedo mezclar ahora si con el HTML, pues solo son datos

Esa(s) funciones, las podrías tener en un include, y mejor si las encapsulas en una clase, así trabajas con un objeto

Código:

Set miObjeto = new Objeto
llamas a todos los procedimientos que quieras
codigo HTML
imprimes resultados
destruyes objeto

En este simple ejemplo, podemos ver un código limpio, no hay razón para extraviar procedimientos...

Desgraciadamente en ASP tradicional, es un poco más complicado o mejor dicho es bastante sencillo mezclar el diseño gráfico de la lógica de tu aplicación, esto me imagino por la flexibilidad que tiene esta plataforma y quizás por algunos problemas de arquitectura, y por malas costumbres de nosotros como desarrolladores que no entendimos los mejores usos de esta plataforma.

Con el tiempo surgieron alternativas para subsanar estos "problemas" como la incorporación de XML - XSL para separar la capa lógica de nuestra presentación.

Finalmente, si programas de una manera limpia, no crearás telarañas que al final no podrás desenrredar ni tu mismo, no hablemos de que venga o otra persona a tratar de hacerlo, espero que nunca te pase que "algún genio" haga una telaraña y abandone el proyecto y llegues tú al rescate...y taráaaannnn, te encuentras con que ese código no tiene ni piés ni cabeza, al final decidirás escribir uno nuevo.

Solamente para responder a la pregunta inicial, dicen los que saben que "aparentemente" al terminar la ejecución de un script, el IIS destruirá todos los objetos que no se encuentren destruidos, pero según no es verdad, así que si no lo haces por costumbre, tu aplicación tendrá una carga extra por todos esos objetos que solo porque no se te antojó revisar tu código no cerraste.

Salu2,

[FiNo]

Esta bueno eso de que no se me antojo, ja; pero gracias por la respuesta, aclaro mi duda y por su explicación.

[El_Metallick]

muy interesante lo que plantea U_G pero me entra una sola duda.... yo suelo trabajar asi.... pero hay veces que se me escapa un end function al no cuplirse una condicion... como puedo hacer para que ASP me obligue a tener una estructura asi??? me imageino que no se puede o si???? o un programa que te obligue??? saludos

[u_goldman]

No entendi, como es que se te escapa un End Function?

Salu2,

[Myakire]

Bueno, si alguien le ve problema a cerrar las conexiones por que nunca aprendió programación estructurada (ni hablar de POO) y de manera intuitiva la programación spaghetti, pues supongo que merece que el servidor se cargue de conexiones inexistentes esperando que el IIS las borre solo. Esperemos que no trabaje con objetos de pago que solo tienen licencia para N objetos concurrentes.

Lo mímino que alguien así puede empezar a utilizar a fin de arregadicar este mal vicio, es el uso OPTION EXPLICIT.

[El_Metallick]

U_G me refiero a que aveces se me olvida poner el fin de la funcion siesque algo falla.... saludos

[u_goldman]

Podrias poner un ejemplo en el que se te presente esta situacion? es que todavia no entiendo muy bien a que te refieres.

Salu2,

[El_Metallick]

bueno aver te pongo un ejemplo mejor con exit function que se me ocurre mas facil

function nombre()
If condicion Then
'lo que se tiene que ejecuter si todo va bien
Else
exit function
End If
end function

estas se me olvidan de poner aveces.... por eso quiero saber si hay alguna forma de obligarme a ponerlos... saludos

[Myakire]

De hecho, ni deberias de ponerlos (los exit function) si estuvieran estructurados los IF's.

[u_goldman]

Asi es, hay muchas maneras de controlar una funcion, como apunta Myakire, si tienes un

Código:

function algo()
  if condicion
    variable = valor
  else
    variable = otro_valor 
  end if
  function = variable
end function

Como ves, aqui si o si, regresas un valor de la funcion, no importando cual sea el resultado, despues dependiendo de ese valor, puedes controlar la ejecucion de tu codigo y esto clarifica aun mas, lo explicado anteriormente, no hay razon para extraviar procedimientos.

Recuerdan que cuando en la universidad(para aquellos que estudiamos sistemas), en las materias que nos ensenaban a programar nos decian: "A cada if corresponde un else", a veces puedes obviarlo, pero regularmente la teoria de los arcanos se cumple y esto no es mas que una buena estructura de datos, un buen diseno de tu aplicacion.

Salu2,

[El_Metallick]

mmm la verdad es que yo estoy recien empesando en la Universidad estoy en primer año de ingenieria civil informatica.... pero al proximo semestre empiezo con fundamento de programacion y ahi vere todo eso que me comentan mas a fondo... osea ahi me va a ser mas claro eso del orden y estructura de mi código... pero de igual manera gracias U_G y Myakire por los comentarios.... saludos

[Neuron_376]

Lo que no entiendo es esto....

function nombre()
If condicion Then
'lo que se tiene que ejecuter si todo va bien
Else
exit function
End If
end function


El exit function, si decias que se te olvidaba, esta bien, el codigo no marca error si no lo poner, pero el END FUNCTION, ese te marca el error si no esta, o no te marcaba el erro ?????

Ahi si me confundi...

Por otra parte creeme que estas aprendiendo mas en este foro que lo que aprenderas en la universidad

Leyendo acerca del orden de programación, en lo unico que no estoy de acuerdo es que con ASP es difícil o separar la parte visual y la parte de código, en mi caso tengo todo por separado, el HTML en una parte y el código en otra, lo cual hace mucho más limpio y mucho más ordenado los programas.

Suerte!!

[u_goldman]

Desgraciadamente en ASP tradicional, es un poco más complicado o mejor dicho es bastante sencillo mezclar el diseño gráfico de la lógica de tu aplicación, esto me imagino por la flexibilidad que tiene esta plataforma y quizás por algunos problemas de arquitectura, y por malas costumbres de nosotros como desarrolladores que no entendimos los mejores usos de esta plataforma.

Salu2,

[Neuron_376]

Me referia en forma general en todo este tema, de que se esta hablando de que la estructura se vuelve muy complicada, pero realmente cuando logras dividir bien las cosas, tu archivo principal no tendría porque tener más de 300 líneas de código, claro, sus respectivos includes, llamadas de funciones, etc., pero el archivo que estas viendo, se reduce de una forma que los objetos, etc., no deben ser difíciles de administrar, y la parte visual si logras dejarla fuera, pues mucho más limpio el código siempre.

Suerte!!

[u_goldman]

Asi es, divide y venceras..!

Ay no, estamos de acuerdo

[Neuron_376]

Pero de todo quieres pelear pues... jajajajajaja

[un_tio]

Iniciado por Myakire

Bueno, si alguien le ve problema a cerrar las conexiones por que nunca aprendió programación estructurada (ni hablar de POO) y de manera intuitiva la programación spaghetti, pues supongo que merece que el servidor se cargue de conexiones inexistentes esperando que el IIS las borre solo. Esperemos que no trabaje con objetos de pago que solo tienen licencia para N objetos concurrentes.

Lo mímino que alguien así puede empezar a utilizar a fin de arregadicar este mal vicio, es el uso OPTION EXPLICIT.

Bueno myakire, no voy a discutir contigo ni responder a tus provocaciones. Atacándome a mí o a un código que no has visto no respondes para nada a lo que había planteado. Me parece que aquí algunos sólo querían presumir de "don perfectos"...

Lo que he dicho está muy claro, e insisto en que mi programa SÍ está estructurado. Sólo que, obviamente, cerrar las conexiones es un trabajo extra (poco o mucho pero algo más).

Y por supuesto, usando como ha dicho u_goldman clases (cosa que no he hecho) se podría estructurar aún más, pero no hay que olvidar que hasta esto va a suponer un trabajo adicional. Y que no contradeciría lo que ya dije aun cuando todo el mundo programara siempre con clases, y es que: ¿para qué cerrarlos? Han dado ya como respuesta porque consumen memoria: pues vale, esto es algo que podría justificarlo (si la memoria perdida es relevante).

Y quedaría por ver si los objetos que no cierra ni el usuario ni el IIS, se quedan "flotando" "toda la vida", o sólo durante un tiempo.

[un_tio]

Por otro lado, y para que la gente entienda mejor lo que quiero decir (en lugar de irse a atacar diciendo que "estará programado a lo spaghetti" o chorradas así), imaginad que vais a una empresa y veis que hay un código hecho por otro trabajador tiempo atrás, en el que no ha cerrado objetos o se ha olvidado de algunos: ¿os merecería la pena poneros a cerrarlos? ¿lo consideraríais de vital importancia?

[El_Metallick]

quisa no de vital importancia pero seria lo correcto.... amigo ademas el master Myakire no lo dice con el animo de atacar... aunque suene un poco a eso peo es la verdad las cosas se deverian hacer asi... o si no bajo los parametros que menciona estan erroneos y eso de todas maneras es problema del programador.... saludos

[Neuron_376]

Hola un_tio, como siempre digo... una disculpa si en mi caso te ofendí en algo, a veces cuando uno lee algo, no puede ver el todo, la expresión de la persona que lo escribió, y es difícil saber su verdadera intención.

Por mi parte, una disculpa si lo malentendiste... pero mira... si se trata de un código que no hiciste tú, pues mejor, no te ofendas, si se trata de un código que hiciste tú, pues que mejor que mires que errores puedes tener, el tener un código bien estructurado depende de muchas cosas, de hecho basa con algo sencillo como tener funciones normales bien adecuadas, etc.

Cierto que a veces hacemos muchas cosas en un solo código, pero debes preguntarte, respecto a esas conexiones extras ???, porque las necesitas, y cuando puedes usar una conexión solamente, lo cual hace todo más eficiente.

Pero bueno, respecto a tu comentario de MEMORIA, la memoria es un recurso muy importante y lo tienes que cuidar, tal vez ahorita tengas una aplicación pequeña, pero recuerda que los malos habitos se quedan, y lo peor es que los habitos son para siempre.

Y bueno, no digo más... Suerte!!

[u_goldman]

Pense en enviarte un privado, pero luego pensé que si las opiniones dadas, se han dado en público, pues también se debe hacer esto públicamente. Estuve releyendo el post entero y puede ser que en algún momento te sintieras atacado (hablo también por Miakyre quien no puede estar porque creo que se fué de vaca )

Creo que las opiniones expuestas, no son para nada con el afán de sentirnos superiores ni "don perfectos", como lo has apuntado, simplemente, me parece que son en pro de toda la comunidad, pues es cierto que es una práctica bastante común dejar nuestros objetos abiertos, pero atención, que esto solamente es una opinión de un servidor, nadie puede juzgar el estilo de programación de otras personas, pero si podemos de cierta manera tratar de ayudar a estandarizar estilos, con el único afán de crecer como comunidad, si las opiniones expuestas te parecieron ofensivas, lo lamento grandemente, pues solamente trataba de explicar, lo que a mi modo de ver, es una mejor práctica para la programación en ASP.

Te ofrezco mis disculpas si te ofendí en algo, solo trataba de crear un punto de referencia, y no es por sentirme perfecto, ni mejor ni nada por el estilo, lo mismo ha pasado en su momento con Neuron por ejemplo, y todo se traduce en que estos cambios de opinión no son sino en pro de todos, al final podemos rescatar "La idea correcta"

Nada mas recordar que todos necesitamos de todos y no hay nadie mejor que nadie, simplemente usuarios mas experimentados o menos.

Salu2,

[Myakire]

y por cierto ....."programación spaghetti" es un término perfectamente válido, buscar al respecto.