FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
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. |
#2
|
||||
|
||||
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
__________________
Daniel Didriksen Guía de estilo - Uso de las etiquetas - La otra guía de estilo .... |
#3
|
||||
|
||||
Cita:
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.
__________________
Be water my friend. |
#4
|
||||
|
||||
Depronto este hilo, te ayude un poco: Eficiencia de consultas paramétricas vs consultas estáticas
__________________
Buena caza y buen remar... http://mivaler.blogspot.com |
#5
|
||||
|
||||
Cita:
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:
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. Última edición por Neftali [Germán.Estévez] fecha: 28-05-2019 a las 14:16:22. |
#6
|
||||
|
||||
Cita:
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#7
|
||||
|
||||
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 |
#8
|
||||
|
||||
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#9
|
||||
|
||||
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í... 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
__________________
Daniel Didriksen Guía de estilo - Uso de las etiquetas - La otra guía de estilo .... |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Querys Dinamicos | Soa Pelaez | Varios | 6 | 03-12-2015 15:19:20 |
Querys Dinamicos Y Rave Reports | FENIXCH | Impresión | 4 | 17-07-2015 00:35:00 |
Agregar múltiples Campo de una tabla a múltiples TEdit y TdbEdit | novato_erick | Varios | 21 | 21-08-2011 02:18:58 |
como generar ventas multiples (seleccionar multiples items) | userdelphi | Varios | 4 | 30-12-2010 03:52:21 |
Valores Fijos de I.V.A. en un DBGrid | gluglu | Varios | 1 | 28-11-2005 11:44:26 |
|