FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
consulta en un IBDataSet
Hola,
Uso delphi6 e IB 7 con dialecto 3. Estoy haciendo una consulta, usando un ibDataSet, que es la siguiente: Cita:
Esta consulta depende del valor que haya para ella, en el parámetro numalu, que lo toma de la tabla Alumnos. Mi Query, QyMatri, está conectada, por el datasource, con la tabla Alumnos, que es la principal del programa. No sé si he hecho mal la consulta, aunque me funciona bien, o cual pueda ser la causa de esto. ¿Alguna idea? Muchas gracias, de antemano. Virginia
__________________
Sonrie al mundo, y el mundo te sonreirá :) |
#2
|
|||
|
|||
Hola,
Además, como los resultados de QyMatri, tiene que mostrarse en un dbgrid que está en el Form principal, y he obserbado que si quito la conexión de dicho dbgrid al DataSource conctado a la consulta, aunque sigua activandose la consulta de un modo interno, la aplicación va más rápida. saludos Virginia
__________________
Sonrie al mundo, y el mundo te sonreirá :) |
#3
|
|||
|
|||
Hola a todos,
creo que tal vez no me estoy explicando bien de que es lo que necesito: El caso es que tengo una tabla, MATRI, cuyos campos son: CAUBAJA, CODIGO, CODVTO, FECFIN, FECINI, NUMALU, NUMEMPLEADO, NUMGRUP Esta tabla está conectada a la tabla ALUMNOS, por el datasource, de la que toma como parametro el valor del campo NUMALU, para tomar de la tabla matrÍculas, SOLO los registros que tengan ese mismo valor en dicho campo. donde el index está en NUMALU Y CODIGO, de modo que un mismo cliente puede tener varios codigos distintos, pero nunca se repetiría, para el mismo alumno, dos veces el mismo código. En la mayoría de los campos de la tabla MATRI guardan los códigos, en número, de los valores que tienen que tener, en array. Así, por ejemplo, CAUBAJA tendrá un valor numérico, por ejemplo 1, que equivale a un único registro de la tabla CAUBAJA que está en la misma base de datos. Esto es, en la tabla CAUBAJA tendremos un campo, CODIGO, en el que entre otros valores, estaría el "1" de antes, donde para ese registro, encontraríamos en el campo DESCRIPCION, el valor array que le corresponde, en este caso, "FALTA DE PAGO". Lo que necesito es una consulta que me muestre los array equivalentes a estos valores numéricos en un dbgrid, buscando en las tablas que corresponda. El código sql que utilizo es el que aparece arriba del todo. Funcionar, funciona. Pero en el momento en el que conecto el dbgrid a esta tabla, comienzan a ir lentos todos los procesos que buscan en la tabla alumnos. No se que puedo estar haciendo mal, creo que tal vez es el código SQL. Alguna idea? Gracias por todo, Virginia
__________________
Sonrie al mundo, y el mundo te sonreirá :) |
#4
|
|||
|
|||
He seguido tu pregunta desde que publicaste el primer mensaje y, la verdad no se que decirte
La consulta es (o almenos eso parece) correcta. Sólo se me ocurren algunas cosillas que podrías mirar 1.- Índices. Es decir, mirar que todas las tablas tengan índices y que sean los correctos para efectuar la consulta. Cuales? Pues por ejemplo, los que hacen unión de las tablas. 2.- Comprobar que se esté utilizando el Plan correcto. Cómo? Pues tendrás que utilizar el componente TIBSQLMonitor para mirar que es lo que hace la sentencia SQL al abrirla 3.- Que las tablas (o alguna de ellas) sea muy grande y, al hacer el join con las demás, esto le cueste (piensa que estás uniendo 6 tablas) 4.- Otra cosa que puedes mirar de hacer es, primero unir las tablas más pequeñas y luego, las grandes. Si no voy equibocado (si lo estoy corregirme), la consulta se va montando según las opciones en el wehere que se tengan, es decir, si primero hacer la unión entre tablaA y tablaB, el resultado de ésta servirá para hacer la unión con tablaC y así sucesivamente (repito, no estoy seguro de esto, pero en As400/DB2 funciona así) 5.- Otra posible causa que se me ocurre es que no estés utilizando todo el índice de las tablas de unión. Es decir, por ejemplo, en mi trabajo tengo una tabla que el índice es TIPO_MOV + COD_ART y tengo otra tabla que el índice es COD_ADT. Pues bien, si las quiero unir, es aconsejable utilizar todo el índice de la primera tabla (aunque tengas que poner algo constante en el primer campo del índice de la primera tabla). Sería algo así selec * from tabla1 a, tabla2 b where a.TIP_MOV = 'C' and b.COD_ART = a.COD_ART Bueno, no se si me he explicado mucho ni si te van a servir mis comentarios. Ya me contarás |
#5
|
|||
|
|||
Hola Cadetill,
Cita:
He estado mirando la sentencia join, pues creo que con ella podría seleccionar una tabla hacer la consulta para ella, con lo que reduciría mucho los registros, y después hacer el resto de los where. Pero, la tabla que más registros me quitaría del medio es ALUMNOS , si filtrase la tabla matri por NUMALU, pues Matri estaría reduciéndose a unos pocos registros. El problema es que NUMALU entra en esta consulta como un parámetro. Tengo conectada la consulta, por el datamodule, al DataSource de alumnos. Si en el selectSQL le pongo que NUMALU=:NUMALU, para cualquier otra tabla, solo con eso, me estaría filtrando los registros, de modo que sólo vería los del NUMALU activo. Pero parece que eso lo hace a la vez que todo lo demás. ¿Cómo hago en este caso lo de juntar las tablas más peques y luego las grandes? Cita:
TbMatri NUMALU, CODIGO TbGrupos NUMGRUP TbPRodu PRODUCTO TbCauBaja CODIGO TbProfe NUMEMPLEADO TbVtos NUMGRUP, CODVTO El único índice que me preocupa algo es, precisamente el de la tabla Vtos, pues no sé si por que la primary key sea de dos campos se tienen que tratar en los where de distinta forma para que no de problemas. Cita:
Muchas gracias, en cualquier caso, pues, como siempre, tus indicaciones me son de mucha ayuda. Virginia
__________________
Sonrie al mundo, y el mundo te sonreirá :) Última edición por Giniromero fecha: 06-11-2003 a las 18:58:06. |
#6
|
|||||
|
|||||
Hola Virginia
Veamos. Si lanzas esta consulta desde otro programa externo a Delphi (IB-Expert o similares) te tarda?? (poniendo, claro está, el NUMALU que quieras) Código:
select D1.NUMALU, D1.CODIGO, D1.NUMGRUP, D1.FECINI, D1.CAUBAJA, D1.FECFIN, D1.CODVTO, D1.NUMEMPLEADO, D2.PRODUCTO, D2.ALIAS, D2.NUMGRUP, D3.PRODUCTO, D3.DESCRIP, D4.CODIGO, D4.DESCRIPCION, D5.NUMGRUP, D5.DESCRIPCION, D5.CODVTO, D6.NUMEMPLEADO, D6.PROFESOR from MATRI D1 inner join GRUPOS D2 on (D2.NUMGRUP = D1.NUMGRUP) inner join CAUBAJA D4 on (D4.CODIGO = D1.CAUBAJA) inner join PROFE D6 on (D6.NUMEMPLEADO = D1.NUMEMPLEADO) inner join PRODU D3 on (D3.PRODUCTO = D2.PRODUCTO) inner join VTOS D5 on (D5.NUMGRUP = D1.NUMGRUP and D5.CODVTO = D1.CODVTO) where (D1.NUMALU=:NUMALU) order by D1.NUMALU, D1.CODIGO Cita:
Cita:
Cita:
Cita:
Creo recordar que no tenía más secreto que ese :s Cita:
|
#7
|
|||
|
|||
Hola Cadetill,
Cita:
Cita:
Cita:
Por cierto, todos estos datos que obtengo de la consulta, los muestro en un DBGrid, y en campos dbEdit o DbLookupcombobox, dentro de la misma pestaña. Lo curioso del asunto, es que si los resultado de mi consulta QyMAtry los muestro SOLO en el dbgrid, esto es, NO vinculo los otros objetos con QyMAtry, el problema de la lentitud se soluciona. y en cuanto los vuelvo a vincular, vuelven a darme problemas de lentitud. Parece un tema de refresco o algo así. En cuanto al resto de lo que me escribes, estoy con ello. Gracias de nuevo por todo, Virginia
__________________
Sonrie al mundo, y el mundo te sonreirá :) |
#8
|
|||
|
|||
Cita:
Cita:
A ver si a alguien se le ocurre alguna cosa al respecto. Por cierto, supongo que estarás utilizando TDbEdits normales y corrientes, no? |
#9
|
|||
|
|||
ya tienes subida a la web la demo sobre el componente.
Espero te sirva |
#10
|
|||
|
|||
Hola Cadetill,
Cita:
En realidad hasta el viernes a última hora no descubrí donde estaba el problema, (siento no haber podido conectarme hasta ahora). El caso es que estaba usando, para casi todos los campos TdbEdits normales y corrientes, excepto para uno de los campos, que estaba usando DBLookUpComboBox, conectado a una tabla no muy grande, pero que, si, efectivamente conecto todos los campos menos ese al datasource de la tabla QyMAtri, me va bien. Por tanto es ese campo el que me da problemas. Supongo que por que cada vez que cambiaba de cliente, también cambiaba la información de este campo, y como se mostraba toda la tabla en ese DBLookUpComboBox, supongo que a los efectos es equivalente ha hacer un locate en una tabla entera de interbase, cada vez que buscaba en el campo el valor que tenía, y lo mostraba en dicho objeto. Vamos, que te puedes morir esperando. En cualquier caso, no he podido probar la demo que has puesto en tu web sobre el TIBSQLMonitor, pues me da el siguiente error. "[Fatal Error] UDemoSQLM.pas(275): Could not create output file '../lib\UDemoSQLM.dcu'" Muchisimas gracias por tu ayuda. Un saludo Virginia
__________________
Sonrie al mundo, y el mundo te sonreirá :) |
#11
|
|||
|
|||
Cita:
Lo siento |
#12
|
|||
|
|||
Hola,
he hecho lo que me indicas. Por desgracia creo que no era sólo eso, parece que además me falta la clase TRxSplitter. Se que esto se obtiene añadiendo packeges, pero la verdad, aunque lo he intentedo en alguna ocasión, pues me habeis intentado ayudar en varias ocasiones con esto, no lo he conseguido poner en funcionamiento nunca, y lo más que he conseguido a sido desconfigurar mi delphi y tener que reinstalarlo de nuevo. La documentación que tengo no me es de mucha ayuda, y no he devido entender correctamente vuestras indicaciones al respecto, por lo que lo he dejado estar. Saludos, y gracias. Virginia
__________________
Sonrie al mundo, y el mundo te sonreirá :) |
#13
|
|||
|
|||
Bueno, el TRxSplitter es un componente de las RxLib, es cual no es necesario para el ejemplo (es sólo para hacerlo más bonito y dinámico), así que puedes pasar de él completamente.
Con lo que respecta a la instalación de Packages, si quieres abre otro hilo (en el foro pertinente) y lo intentamos de nuevo |
#14
|
|||
|
|||
La verdad es que te lo agradecería.
Muchas gracias, Virginia
__________________
Sonrie al mundo, y el mundo te sonreirá :) |
#15
|
||||
|
||||
Hola a todos buscando un hilo donde expliquen como usar el ibdataset me encontre con este hilo y te comento Giniromero que también tengo un sistema para una escuela e igual que tu tenia consultas que desde mi dbgrid eran muy lentas y si las probaba en ibconsole o desde otra aplicación en delphi esta funcionaba bien y a buena velocidad.
Ahora bien la diferencia con el tuyo es que como yo no se usar ibdataset utilizo ibtables, y en el data module tengo las siguientes tablas: Alumnos (con los datos personales de cada alumno) Tutor (con el nombre de los padres de cada alumno) Profesores (con los datos personales de los profesores) Horarios (con la clave del profesor, el grupo, materia y horario de clase) Materias (un catálogo con las materias que se imparten en la escuela) Grupos (con la clave del alumno, grupo y materia que cursa entre otras cosas) Las relaciones entre tablas que tengo establecidas con mastersource y masterfields son de Alumno a tutor, de profesor a horarios de horarios a grupos, y la tabla de alumnos alimenta a la de grupos con la relación establecida en un solo campo y de igual forma la de materias a grupos y horarios. Todas mis tablas tienen campos calculados de diferente índole. Como te comento cuando hacia una consulta para obtener el horario de clases de un alumno por decir algo, mi aplicación se alentaba mucho, y al hacer otra aplicación de prueba solo con esta consulta funcionaba bien, así que depure la aplicación y me di cuenta que al moverme en el dbgrid de dicha consulta delphi checa todos los eventos programados que tenia y recalcula los campos calculados de cada una de las tablas, así que mi solución fue borrar todas las relaciones que tenia entre tablas (no las de un campo a la tabla) y solo activar estas cuando la forma que estoy usando las necesite y al salir de esta forma las borro y con eso solucione mi problema. Espero te sirva ya que por la fecha de tu hilo este tiene más de 15 días . p.d. ¿qué es dialecto 3 nunca lo havia visto?
__________________
Espero poder seguir exprimiéndote el cerebro 8) Jorge Zamora Ginez Puebla, Pue. México |
#16
|
|||
|
|||
Hola,
Lo primero, disculpa que no te haya contestado antes, no me he podido conectar en estos días a internet. Te agradezco lo que me comentas de el DBGrid, de todos modos, ese problema, es más notable cuando usas IBTables, por eso yo me cambié a IBdataSet. El IBDataSet, está basado en consultas SQL que reducen el nº de registros con los que se trabaja, de modo que se mitiga la desagradable lentitud que tiene IB en una rutina de busqueda secuencial. Digamos, que no entiende eso de "ultimo y primer registro" y en cuanto la tabla es algo grande, te mueres esperando. Este objeto IBDataSet es muy facil de usar, aunque vas a necesitar un poco de SQL, pero si estás usando Interbase, entiendo que te es necesatio. Además, para generar tablas, tal cual las tienes con los IBTable, sólo tiene que en la propiedad SelectSQL definir que tabla y que campos, el order by que necesita tu tabla y el resto del SQL (DeleteSQL, UpdateSQL ...), lo puedes generar despues de esto, simplemente, ejecutando "DAtaSet Editor", al que se accede con el botón derecho del ratón sobre el objeto DataSet. Por si te interesa, te facilito la dirección de un "curso" de SQL que te puede ser de ayuda: http://www.infonegocio.com/tudela2/d...cs/sql/sql.htm El dialecto 3 se refiere al "tipo" de SQL que utilizamos en nuestra base de datos IB. Esto tiene implicaciones de cara a los tipos que podemos usar, entre otras cosas. Yo lo estoy utilizando, por que este dialecto permite tener campo de sólo horas, o sólo dias o ambos juntos, según se necesite, mientras que el dialecto 1 sólo deja campos que tienen fecha y hora juntos. De todos modos en internet hay información sobre los distintos dialectos, no te he conseguido encontrar la página que yo me leí, para aclararte esto mejor, pero esta puede ayudar: http://www.clubdelphi.com/ib/articul...has/fechas.php Un saludo, Virginia
__________________
Sonrie al mundo, y el mundo te sonreirá :) |
#17
|
||||
|
||||
Gracias por las ligas las estoy leyendo, te comento que ya estoy haciendo pruebas con ibdataset pero estoy teniendo problemas a la hora de usar los códigos de updatesql, deletesql, etc. por ejemplo actualizo los datos de un registro de la base, los guardo con post, cuando cambio salgo de la aplicación y vuelvo a entrar encuentro que este registro sigue con la información original y no la que actualice, lo mismo no me aparecen los registros nuevos, siguen en la base los que habia borrado, supongo que me esta faltando alguna instrucción y espero encontrar esta en las ligas que me mandas.
gracias
__________________
Espero poder seguir exprimiéndote el cerebro 8) Jorge Zamora Ginez Puebla, Pue. México |
#18
|
|||
|
|||
Hola,
por lo que me cuentas no los has definido bien. Bien por que te falta código en los eventos, esto es: eventos AfterCancel procedure TFrmDModule.AfterCancel(DataSet: TDataSet); begin IBTransaccion.RollbackRetaining;//o Sin el Retaining end; y para los eventos AfterPost procedure TFrmDModule.AfterPost(DataSet: TDataSet); begin IBTransFX.CommitRetaining; end; No sé si saber que cada vez que modificas un registro, o lo intentas, en IB se queda abierta la transacción, y hasta que no actualizas esa transacción, los datos no se guardan realmente. Otra posibilidad es que no tengas bien definida la transaccion, el como quieres que esta funcione. Para ello tienes que ir a la transacción que tienes vinculada a tu base de datos, con el botón izquierdo del ratón haces doble click y te saldrá una ventana, "Transaction Editor". Prueba con "Read Committed", que te generará el siguiente código: read_committed rec_version nowait Esto, actualiza la aplicación a cada cambio para que se actualice la información en cualquier terminal que este usndo esa misma base de datos. La última posibilidad que se me ocurre pueda estar dandote problemas, es que no hayas generado bien el código para UpdateSQL, deleteSQL etc... eso lo puedes solucionar con el botón derecho del ratón sobre tu IBDataSet, en "dataset editor" En key field tienes que poner el campo que es primary key en nuetra tabla, si lo tienes ya definido en la propia base de datos, pulsando "Select Primary key" se selecciona solo. En Update Fields, tienen que estar los campos que vas a querer que se actualicen. Si son consultas sobre una unica tabla, probablemente quieras que sean todos los campos, pero si tienes una consulta en la que aparecen varias tablas distintas, entonces te puede dar problemas si seleccionas campos calculados, o campos que no sean de la tabla principal de tu consulta. Cuando hayas definido todo esto, no te olvidas de pulsar "Generate SQL" para que te genere automaticamente el código para el delete, Update y ModifySQL. Espero que te haya sido de ayuda, Saludos Virginia Para que estas transacciones se acualicen es para lo que sirven los procedimientos que te comento insertes en tus tablas. Cuando usas RollBack, cancelas lo que hayas hecho en esa transacción, cerando las tablas. Cuando RollBackRetaining también te cancela lo que hayas hecho en esa transacción pero sin cerrarte las tablas. El commit te guarda los cambios cerrando tablas, el CommitRetaining sin cerrarte tablas. (Si tienes dudas sobre esto, te aconsejo busque en la documentacion que tengas de interbase, y en internet.)
__________________
Sonrie al mundo, y el mundo te sonreirá :) Última edición por Giniromero fecha: 15-12-2003 a las 09:28:40. |
#19
|
||||
|
||||
quote:
-------------------------------------------------------------------------------- Giniromero comentó: Bien por que te falta código en los eventos, esto es:................... --------------------------------------------------------------------------------- muchas gracias estoy seguro que este es mi problema ya que cunado uso el ibconsole tengo que hacer un commit y suponia que es lo que me falta en delphi, probare esto que me dices y de nuevo gracias
__________________
Espero poder seguir exprimiéndote el cerebro 8) Jorge Zamora Ginez Puebla, Pue. México |
#20
|
|||
|
|||
De nada, aunque las gracias se las tendrías que dar a la gente de este foro, (cadetill, guillotmarc...), que me orientarón en todo esto, gracias a lo cual, te puedo ayudar a ti ahora.
Saludos, Virginia
__________________
Sonrie al mundo, y el mundo te sonreirá :) |
|
|
|