consulta en un IBDataSet
 

Hola,

Uso delphi6 e IB 7 con dialecto 3.

Estoy haciendo una consulta, usando un ibDataSet, que es la siguiente:

El problema es que, hasta que inserté esta consulta en mi programa, la aplicación iba bien, pero desde entonces, va lento.

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

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

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

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

Hola Cadetill,


También yo estaba planteándome esta opción, pues, efectivamente, una de las tablas es muy grande, concretamente la tabla Vtos.

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?

Los índices que tengo para las tablas, configurados en la base de datos, son:

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.



En cuanto a esto... no lo he usado nunca, y tras leer tu e-mail he intentado configurar uno en mi aplicación y se ha quedado colgada al compilarla. :confused: ¿Podrías, por favor, decirme como va?

Muchas gracias, en cualquier caso, pues, como siempre, tus indicaciones me son de mucha ayuda.:D

Virginia

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)

PD: he modificado algo la consulta, pero en el fondo es la misma

En la consulta la he puesto al final. Mira de jugar un poco con ello a ver si ganas tiempo

Cuando lanzas un SQL, no puedes primero lanzar un cacho y luego otro :p Si se lanza, se lanza toda, sino, no se lanza ;) Lo que te comentaba en el mensaje anterior era que, primero, hicieras las uniones con las tablas pequeñas y luego con las grandes. Para ello, sólo has de cambiar el orden de los AND o bien (si sigues mi ejemplo, el de los inner join

En principio lo haces bien, ya que estás utilizando todo el índice (y no parte de él) en la consulta. Si utilizas parte, pero es por orden de campos importante (es decir, en tu caso el de más peso sería NUMGRUP y luego CODVTO) no pasa nada tampoco. Sólo es cuando utilizas parte del índice pero que no por orden de importancia (no se si me explico :s)

Bueno, yo sólo lo utilicé una vez por el tema de un SQL que tb me iva lento. Lo que has de hacer es decirle que quieres que te trazée (TraceFlags) que, en principio creo que con Prepare, Execute y Fetch tendrás suficiente. Luego, has de capturar el único evento que tiene (OnSQL) y, por ejemplo, lo vas añadiendo a un TMemo (recives como parámetro el evento y la fecha/hora) o a un fichero de texto.

Creo recordar que no tenía más secreto que ese :s

Pues de nada ;)

Hola Cadetill,

Vale hasta aquí OK, pero...

Perdona por la torpeza, pero, ¿cómo hago esto? ¿Como le asigno los datos al campo memo o como los guardo en el archivo?, por que se como asignarle valores a un campo memo, pero no como tratar los valores que se obtienen delTIBSQLMonitor.

Si esta consulta la escribo en IbExpert me muestra el resultado de un modo inmediato. Por lo que, ya no parece tanto un problema de código SQL.

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.:confused: :confused:

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

Bueno, he hecho un pequeño programita demo que lo subiré esta noche al llegar a casa a mi web para que lo puedas descargar


Pues la verdad no sabría que decirte, nunca me he encontrado con esto :(
A ver si a alguien se le ocurre alguna cosa al respecto. Por cierto, supongo que estarás utilizando TDbEdits normales y corrientes, no?

ya tienes subida a la web la demo sobre el componente.

Espero te sirva :)

Hola Cadetill,

Creía que esto lo había aclarado en anteriores respuestas, pero parece que no :o, lo siento, seguramente habría descubierto antes cual era mi problema.

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

Me colé al poner los paths :o Puedes cambiarlos tu misma en Project/Options/Directories-Conditionals y, en lugar de poner "/" pones "\".

Lo siento :p

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

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

La verdad es que te lo agradecería.

Muchas gracias,

Virginia

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?

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

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

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.)

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

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

¿Es realmente necesario RollbackRetaining en estos casos?
 

¡Buen día a todos!

He leído algunos documentos que hablan de usar los métodos de TIBTransaction, CommitRetaining en los eventos AfterPost y AfterDelete de los conjuntos de datos, y RollbackRetaining en el evento AfterCancel.

Comprendo la utilidad de los dos primeros, pero no se exactamente con qué fin se utiliza RollbackRetaining en AfterCancel, cuando por lógica (aparentemente) no hay nada que deshacer transaccionalmente hablando. Ya que, hasta ese punto, los datos que se hayan introducido en una inserción o modificación de registro están sólo en la memoria del conjunto de datos en la aplicación, y al cancelar, pues simplemente desaparecen de la memoria del programa sin que se haya afectado a la base de datos.

Les agradezco que me orienten con la anterior duda.

Agrego, que en uno de mis proyectos IBX-Firebird, estoy utilizando las propiedades DefaultAction = TACommitRetaining e IdleTimer = 250 del objeto TIBTransaction principal. Dejar de usar estas propiedades no sería mucho problema, ya que desarrollé componentes derivados de los IBX, en los cuales podría implementar internamente las llamadas a CommitRetaining y RollbackRetaining necesarias. Pero... ¿para qué RollbackRetaining?

Un abrazo, chao.

Al González :).

Hola lo que entiendo es que como dises los datos estan solo en memoria pero que pasa si como tu dices no usas RollbackRetaining cuando quieres concela y en algun otro momento de la aplicación quieres guardar o borrar informacion con CommitRetaining los datos que deberian haber sido borrados con RollbackRetaining aun van a estar en memoria y por lo tanto se guardaran con el CommitRetaining ya que no tenemos un control real de que información esta o no en memoria.

Bueno en mi forma de entender las cosas eso es lo que esta pasando ojala y alguno de los expertos nos diera su opinión.