Querys fijos o multiples dinamicos?
 

Buenas noches gente

Mi consulta es la siguiente, tengo varias units donde algunas son principales (con formulario) y otras que sirven de apoyo.
La cuestion es: es conveniente que un procedimiento si necesita consultar a la base de datos algo cree un componente TADOQuery dinamicamente y al finalizar el procedimiento lo destruya? o conviene que la unit tenga una variable TADOQuery global que se conecte cuando inicia el software y permanezca siempre conectada?
Mas que nada por la cantidad de conexiones activas cuando el software empiece a crecer ya que esta en etapas inciales.

Desde ya Muchas gracias.

Hola.

Siempre es conveniente crear un recurso cuando se lo necesita y liberarlo cuando ya no se lo precise, es el tratamiento mas eficiente de los mismos. Es decir, ¿ Para que tener todas las consultas abiertas consumiendo recursos todo el tiempo si sólo se usarán algunas en determinado momento ?
Por otro lado, la creación de recursos por demanda no impide la utilización de todos ellos en un momento si eso fuera necesario.

Saludos :)

Compañero... saludos :).


Yo en particular hago una cosa mixta, es decir, si preveo que un recurso se va a utilizar con frecuencia lo dejo creado para darle más agilidad a los procesos. Por otro lado, y para temas poco habituales, los creo y destruyo una vez usados.

Depronto este hilo, te ayude un poco: Eficiencia de consultas paramétricas vs consultas estáticas

Creo que en este caso está confundiendo 2 cosas diferentes (o las estás mezclando cuando no debería ser así).
Una cosa es la consulta TADOQuery y otra cosa es la conexión TADOConnection.

Abro paréntesis.
En este caso ADO tiene cierta culpa, porque en un TADOQuery puedes definir también la cadena de conexión. En algún caso esto puede ser beneficioso (para ahorrar un componente TADOConnection), pero en otros puede ser confuso.
Cierro paréntesis.

Crear un TADOQuery es poco costoso al igual que otros componentes. Lo que realmente tarda es "realizar la conexion" (sea desde un TADOConnection o desde un TADOQuery).
Además lo que tampoco sería nada correcto es crear una conexión por cada TADOQuery que necesitemos.

En este caso estoy de acuerdo con [Casimiro] y optaría (normalmente lo hago así) por una solución mixta.

1) Crear un TADOConnection en un lugar accesible y conectarlo.
2) Crear TADOQuery cuando sea necesario y destruirlos cuando ya no se usen y conectarlos a elemento del punto 1.



De esta forma:

• No consumes tiempo innecesario en conectar.
• No consumes más conexiones de las necesarias.
• Creas los componentes cuando los necesitas y los destruyes cuando ya no son necesarios (en tu caso los TADOQuery). Por lo tanto, no consumes memoria nnecearia.

Me has leido el pensamiento :)

A mi también me parece que se están mezclando cosas. Yo quisiera apuntar que "crear un componente TADOQuery dinamicamente y al finalizar el procedimiento destruirlo" es algo muy feo para hacer. Los componentes TADOQuery y similares están para una mejor organización del código, para empaquetar correctamente las distintas funcionalidades de un sistema. Crear compontes de este tipo al vuelo es lo mismo que insertar consutas SQL al vuelo sin ninguna organización, mezclando código de acceso a BD con código de gestión. Y eso es muy feo.

Los TADOQuery (y similares) deben situarse en tiempo de diseño en su respectivo DataModule y enlazar a ellos desde formularios y demás. En todo caso, lo que puede crearse al vuelo es el DataModule en sí, aunque tampoco lo veo muy necesario a no ser que hay una cantidad considerable de ellos. Todos los ADOQuery se conectan a un sólo TADOConnecion, como ya mencionó Neftalí, de manera que en ese aspecto no hay un uso extra de recursos.

// Saludos

Pienso igual. Ya sean "ADO", "IBX", "FIBplus", etc.

Hola.

La confusión fué mia que interpreté que la cuestión se trataba sobre dejar las consultas siempre conectadas o abrirlas y cerrarlas en la medida que se precisaran. Realmente no sé que fué lo que leí... :o

Aclarado ese punto coincido en que no se gana en la creación dinámica del componente en sí, siendo mucho mas conveniente situarlos en diseño en un TDataModule tal como ustedes indican y siempre he hecho.

Saludos :)