Consulta de una Consulta
 

Mi pregunta es si se puede hacer una consulta de una consulta el Delphi.

Esto es, hago una consulta SQL ( ya sea a tablas de dbase IV o a tablas de MS Server ) y luego, teniendo ya los resultados, usar otro componente y a través de una instruccion SQL obtener un subconjunto de registros.

Se puede ?

Lo puedes hacer tambien desde SQL Server

Código SQL [-]
select T.Articulo
from (select Articulo, Precio from Articulos) T
where T.Precio > 100

ejemplo muy sencillo pero espero que te de una idea

jejeje
 

Nop, necesito liberar carga del servidor, quiero cargar todo el SQL en una tabla de memoria (memtable) y luego de alli hacer varias consultas SQL.

Tu ejemplo funciona, pero es carga sobre el servidor.

Hola a tod@s:

Yo creo que la pregunta de Ing_Fajardo habría que plantearla de otro modo: ¿existe alguna modo de hacer una consulta SQL sobre los datos almacenados en cualquier DataSet? Por ejemplo, hacer una consulta sobre los datos almacenados en un TRxMemoryData de la librería RX?

Esto sería muy útil.

Saludos.

Hace algún tiempo yo también intenté algo así... pero no conseguí resultados y opté por hacerlo mediante código Delphi, pero es una solución que no me convence.
Si alguien sabe cómo se hace :) a mi también me sería de gran ayuda.

Uff

La cosa está chunga

Se me ocurre descargar la primera consulta en un fichero XML, datapackets a ser posible, si ya conoces la estructura del XML de ante mano.

Una vez cargado esa consulta primera en un fichero XML, hacer consultas sobre ese fichero XML es muy rápido y fácil (siempre desde Delphi 6).

Pero necesitas saber el schema del fichero XML desde el inicio para que vaya rápido el uso de XML's. Si tu consulta es fija, es decir, siempre devuelve los mismos campos, puede ser una buena opción

Si necesitas más ayuda, o te decantas por esta opción, avísame y te puedo mandar algo sobre el uso de ficheros XML como base de datos en Delphi

Alternativa a consulta de una memtable
 

He tenido el mismo problema y no he visto solución, asi que he optado por otra alternativa. Me he creado una nueva tabla en la base de datos y la he utilizado de manera auxiliar, es decir, el resultado de las consultas que hago lo he almacenado en dicha tabla. Despues realizo consultas sobre esta nueva tabla y cuando no me sirve borro sus datos.

Esta solución es facil de implementar pero desconozco la carga en el servidor que se pueda incrementar o si afecta demasiado a la velocidad del programa.

Una preguntilla para los entendidos en el asunto. ¿Un programa como trabaja mas rápido haciendo megaconsultas (de varias tablas) en SQL o bien intentar simplificarlas en consultas mas sencillas y utilizar bucles?

Yo prefiero las "mega consultas" como tu las llamas, esto es porque solo sería 1 consulta. Ahora que si lo haces en un ciclo, tendrías que esperar a que el sistema ejecute el ciclo y a que el servidor te regrese la misma consulta muchas veces. Esto tal vez no lo notes en ciclos pequeños, pero por experiencia te digo que cuando la información es mucha, el sistema puede parecer muy lento (y no quiero entrar en polémicas sobre cuando es mucho)

Como ejemplo te diré que hay un sistema que lo realizaron de esa manera, con ciclos, repitiendo la misma consulta una y otra vez... cuando los parámetros eran pocos, no había mucha diferencia, pero al aumentar los parámetros, la pantalla se cargaba de entre 11 a 15 segundos. A diferencia de una "mega-consulta" con todos los parámetros posibles, se cargaba en 0.10 segundos.

Yo me inclino también por "mega-consultas" si con eso entendemos que afectan a varias tablas o que muestran muchas columnas.
Sin embargo hay que tener cuidado con esas consultas para que no alcancen un grado de complejidad que las haga demasiado pesadas para el SGBD. Si llegamos a ese punto entonces hay que rediseñar la consulta o dividirla o algo.

Pero para eso casi todas las BD tienen alguna herramienta para medir el grado de complejidad: Pasa tu consulta por el que tengas disponible y decide tú mismo si eso es asumible en tú sistema o es mejor partir.

La carga del servidor... ¿a qué se refiere?

Si se le da dos consultas anidadas, el plan que pueda ejecutar tu SGBBDD puede ser más optimo que lo que planteas, además, puede que de las dos consultas solo tenga que regresar digamos... 100 registros, mientras que de la primera consulta, quizás deba regresar 1000 registros. En este caso es preferible cargar al SGBBDD en lugar de sobrecargar nuestra aplicación con memorytables, consultas de consultas, problemas de sincronización de datos con los datos existentes en el servidor, etc.

Respondiendo a las dudas, la solución creo que es un ClientDataset que de hecho permite agregar campos calculados, ordenar en el cliente y algunas cosas más.

Si además se le añade CacheUpdates, tendremos del lado del cliente la posibilidad de eliminar registros, crear algunos nuevos, etc todo en memoria. Solo se envían los resultados al hacer un ApplyUpdates.

Usa el Buscador, google y la propia ayuda de delphi.

Saludos

el ejemplo de los selects anidados funciona perfecto pero hay que tener en cuenta que el segundo select se ejecuta cada vez que se optiene un registro del primer select, de manera que si vamosa traer 100 registros terminamos ejecutando 101 querys (el query que inició o principal y 100 subquerys, uno por registro) En ese caso es mejor usar joins.

Lo que quiere hacer el inge prácticamente no se puede a no ser que haga chapuzas por ahi. No entiendo cual es el chiste de contar con un servidor dedicado para correr la BD si terminamos haciendo las consultas en forma local..

Firebird, MySQL, Postgress, DB2, MS-SQL, etc. son motores de BD preparados para realmente hacer trabajo pesado: miles de consultas, miles de registros, etc. por lo que no nos debe dar miedo cargarlos. Obviamente esto requiere tener todo el poder de cómputo que podamos comprar.

Si pasamos el trabajo de correr querys a cada cliente no sacamos ningún provecho de un motor, y seria mas facil usar tablas planas, hacer un query para traer los registros que queramos, guardar el query como una tabla en forma local y luego ejecutar otro query sobre esta última tabla...pero insisto, no le veo caso.