FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Tantos TQuery como consultas deseo?
Hola a todos nuevamente, sigo muy agradecido por toda la ayuda brindada por el foro, y deseo mucho algun dia poder colaborar de la misma manera q lo hacen ustedes.
Estoy queriendo aprender un poco de SQL y mi pregunta es esta. yo a una tabla le puedo hacer muchas consultas, pongamos un ejemplo Tengo una tabla de productos, y quiero buscar uno, tambien quiero controlar q ningun producto tenga stock= 0 y alguna otra q ustedes se imaginen. otro ejemplo: O buscar un producto por nombre, o codigo, o lo q fuese, tengo q poner un TQuery para cada busqueda y activar cada query con una accion de un boton o de otro componente. Como seria la cosa? Sigo usando paradox 7! Gracias! |
#2
|
||||
|
||||
Hola, no amigo no es necesario un TQuery por cada búsqueda, con uno basta ejemplo:
en este ejemplo estoy usando un sólo Query. Saludos.
__________________
Mi BLOG - ¡Joder, leanse la guia de estilo! Las Palabras son enanas, los ejemplos gigantes. |
#3
|
||||
|
||||
Yo creo que es cuestión de organización. Si vas a usar un solo query para todas las consultas, posiblemente signifique o implique que vas a tener tus consultas desperdigadas por todo el código. Puede ser preferible tener las partes limpiamente separadas.
// Saludos |
#4
|
||||
|
||||
__________________
|
#6
|
||||
|
||||
Puedes hacer un solo query para consultar por uno o varios campos así:
Solo tienes que llenar los parámetros según requieras, si no llenas ninguno te va a traer todos los registros. Esta es una forma muy sencilla de hacer combinaciones de condiciones y utilizas un solo query. De esta manera podrias traer por ejemplo: todos los productos que contengan "PRO" en su nombre y que tengan stock de mas de 10. Para ello llenamos los parametros así:
__________________
AKA "El animalito" ||Cordobés a mucha honra|| |
#7
|
||||
|
||||
tómala, jejeje
__________________
|
#8
|
||||
|
||||
Ja,jaa,jaa,ja,ja,jaa, me sorprendieron.
Esta muy bueno, es lo que necesitaba tambien.......
__________________
"Pedid, y se os dará; buscad, y hallaréis; llamad, y se os abrirá." Mt.7:7
|
#9
|
|||
|
|||
Gracias!!
Ahora manos a la obra y analizar y probar las soluciones q brindaron para ver cual es la q mas se adecua a mi situacion.
Cualquier sugerencia por favor, estaria bueno q la sigan posteando! Gracias, salu2!! |
#10
|
|||
|
|||
te explico como trabajo yo : tengo ciertas querys generales que son las ligadas a las dbgrids. En ellas aplico los filtros necesarios etc, con nombres bien distinguibles (dmsrc.queryClientes,etc...). Para todas las otras operaciones (pasar datos de una a otra, encontrar un identificador concreto, cambiar campos relacionados etc...) entonces creo otra query correspondiente en la misma funcion en que se hace la operacion. Asi siempre tengo las querys 'visibles' mas o menos controladas. Es una manera personal, claro. Cada uno tiene la suya.
|
#11
|
||||
|
||||
Concuerdo con lo que comenta coso y a eso me refería. Intentar reutilizar un sólo query para todas las consultas, tarde o temprano lleva a confusión.
Otra cosa. Acabo de probar la propuesta de AzidRain, y si bien me funciona con MySQL usando las componentes MyDAC, no así con Paradox usando el BDE. La consulta marca el error de "Type mismatch in expression" tanto si le paso valor al parámetro como si no. // Saludos |
#12
|
||||
|
||||
Yo utilizo una opción mixta, para los casos particulares utilizo un Tquery para cada consulta incluso con campos persistentes. Pero para cosas generales como conteos, sumas, búsquedas...
Utilizo un Tquery sin campos ni contenido alguno y construyo por código el SQL que en cada momento necesito. Un Saludo.
__________________
Guía de Estilo de los Foros Cita:
|
#13
|
||||
|
||||
Yo soy partidario de crear consultas específicas y otras generales...
por ejemplo, mis diseños tiene en un Form la opción de mostrar un registro, agregar, eliminar y actualizar.... para esos tipos de Formularios siempre utilizo 3 consultas... Como trabajo con ADO, las pondré así 1.- AQ_Select -> con la cual realizaré una selección de todos o parte de los registros 2.- AQ_Edit -> con la cual realizaré una inserción y/o eliminación 3.- AQ_Actualiza -> con la cual realizaré una actualización de un registro Ahora, si necesito algo más específico, pongo tantas consultas como sea necesario y reutilizandolas al máximo....(tambien me debo acordar de lo que uso...) bueno, si me baso en lo que dije, en un sistema donde tengo Clientes, Productos, Proveedores, Vendedores, Centros de Costos, y otros similares.... si bien es información diferente, con las 3 consultas anteriores cubro todas las consultas para cada uno de los Formularios... Bueno, al menos así lo hago yo.. Salu2
__________________
BlueSteel |
#14
|
||||
|
||||
Hola a todos... Yo en mi caso ahora estoy provando una nueva forma de organizarme... vamos a ver como ve con esto...
Uso los componentes IBX y Firebird; lo que hago basicamente es crear un conjunto de componentes (TIBTransaction y TDBDataSet) por cada tabla automaticamente con la funcion CrearCompDB, el cual el mismo me genera el codigo SQL básico para editar, insertar, borrar y actualizar registros (ya que es muy tedioso hacerlo cuando tenes muchas tablas ) cada conjunto de componentes es usado por lo modulos que editan sus datos. Ademas tengo un modulo para busqueda simple el cual arma la consula dependiendo de la tabla que se vaya a consultar y muestra los campos en un grid, el cual abre el modulo correspondiente a la tabla que se esta consultando cuando se hace doble click en un registro del resultado... En fin... no soy muy amigo de lo estatico y prefiero que el programa vaya armando y manipulando las consultas y componentes que se conectan segun la demanda del usuario.... Claro que hay que tener cuidado con el codigo para no consumir mas recursos de los necesarios. La funcion que uso para crear los componentes y el codigo SQL basico
Saludos a todos |
#15
|
||||
|
||||
Roman en el caso del BDE, me parece que hay que construir y definir los parámetros previamante. Tanto MyDAC como Zeos hacen la conversión de tipos al vuelo y no requieren que se los definas previamente. Checalo.
__________________
AKA "El animalito" ||Cordobés a mucha honra|| |
#16
|
||||
|
||||
Creo que no Azid. Si quito la parte de
funciona bien sin necesidad de definir los parámetros. El tipo de datos se determina cuando usas ParamByName(...).AsXXX Si asigno previamente el tipo de datos, sigue marcando el error. // Saludos |
#17
|
||||
|
||||
elcolo83:
Tu idea es muy buena, pero quizá estás reinventando la rueda. Me explico: No sé cómo funcionen los componentes IB, pero en otros similares, si pones una sentencia como esta:
en la propiedad SQL, puedes hacer inserciones, actualizaciones y supresiones sin necesidad de especificar nada más. Incluso, por ejemplo, si modificas un registro, el SQL que se genera incluye sólo los campos modificados, mientras que como lo haces, siempre se incluyen todos. Más aún. Si sigues el truco de AzidRain y pones la sentencia
entonces también te sirve para hacer selecciones. Las propiedades InsertSql, UpdateSql y DeleteSql, creo que están más para casos en que se involucren varias tablas y la sentencia SQL adecuada no pueda deducirse en automático. // Saludos |
#18
|
||||
|
||||
Roman
Sinceramente nunca habia provado la sentencia con los IBX, mañana lo provare... si anda, seria genial ya que eliminaria la parte del codigo que me genera el codigo sql solo dejaria las lineas que crean los componentes para que mi sistema funcione... Muy buena data... gracias, despues te cuento como me fue |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Deseo.... un vinculo o una serie.... | georkis | PHP | 8 | 22-06-2008 06:25:04 |
No me guarda el fichero en el directorio que deseo | kapullok_2006 | Varios | 4 | 22-11-2007 10:21:17 |
Nunca se vieron tantos hombres y tantas patadas | marcoszorrilla | La Taberna | 3 | 25-04-2007 19:49:47 |
Deseo instalar SQL en Delphi 7 | JuanchoRM | SQL | 5 | 27-07-2006 10:22:31 |
Imprecion a tantos cm... | marce | Impresión | 1 | 09-12-2003 16:23:49 |
|