www.clarioneros.com

El rincón de los desarrolladores
Fecha actual Sab Nov 18, 2017 11:51 am

Todos los horarios son UTC




Nuevo tema Responder al tema  [ 7 mensajes ] 
Autor Mensaje
NotaPublicado: Mié Oct 18, 2017 3:50 pm 
Desconectado

Registrado: Mar Mar 01, 2011 8:36 pm
Mensajes: 109
Hola gente!

Desde hace un tiempo he migrado mis viejos sistemas en TPS a SQL utilizando el motor FireBird. Como bien diría Mauricio en sus tutoriales, uno le vende a sus clientes que con SQL todo irá mejor y más rápido y después se encuentra con que en determinados procesos la lentitud es considerable. Por eso con el tiempo he ido optimizando los mismos tratando de aprovechar los beneficios de SQL, y resolviendo las trabas a medida que se iban presentando, muchas veces con ayuda de los foreros que me ha sabido desasnar en más de una ocasión! :)

Pero si hay algo que aún me da vueltas y no he encarado por el momento, es el tema de los Browses. Me parece super práctica la manera en que el wizard de Clarion crea las ventanas con Browse y sus botones para ABM que llaman a los forms, y si bien he tenido la precaución de que la carga de los mismos sea paginada, a medida que las tablas crecen se va incrementando la lentitud de carga y búsquedas en las ventanas.

Por poner dos ejemplos claros:

1) Típica ventana de consulta o búsqueda de artículos con múltiples lengüetas para buscar por código, descripción, rubro, palabras, etc. Ya de movida si la tabla tiene 20.000 o 30.000 registros el sólo abrir la ventana por primera vez implica una demora de 2 o 3 segundos. Si se quiere utilizar la búsqueda incremental o los locator filtered por cada letra que uno ingresa hay un "parpadeo" en la lista que se torna molesto. Ni hablar si el sistema se está usando en una PC cliente de red y las máquinas son clones estándares con una memoria y un procesador bien básicos.

2) Carga de tablas con formato PADRE-HIJA, por ejemplo, Facturas con sus detalles, o presupuestos, o similares. Asumiendo que el detalle utiliza la búsqueda mencionada en el punto 1), una vez que se encuentra el artículo buscado y se selecciona, hay una demora de 1 o 2 segundos hasta que el mismo se carga al browse de detalle (siempre hablando de tablas con miles de registros)

Por esta razón, quería contactarme con alguien que pudiera ayudarme a optimizar estos aspectos, ya que tengo algunos clientes con tablas muy muy grandes que necesitan una velocidad de proceso rápida y eficiente. Saliendo de la ayuda que me puedan brindar a través del foro, quisiera contratar a alguien part-time, como una especia de "tutor" con quien ir resolviendo cuestiones como esta a través de ejemplos concretos de código.

Si alguien está interesado, le dejo mi mail para que me contacte por privado: ilepetersen@hotmail.com

Muchas gracias y saludos! Ileana


Arriba
 Perfil Email  
 
NotaPublicado: Dom Oct 22, 2017 6:19 am 
Desconectado

Registrado: Dom Feb 06, 2011 9:43 pm
Mensajes: 68
Ubicación: Montevideo - Uruguay
Hola, sabés que hace un tiempo estuve testeando Firebird porque nunca había hecho nada con SQL y me pasó lo mismo, al cargar muchos registros de prueba noté que todo se vuelve más lento. Luego probé con FM3 de Capesoft y fue distinto, todo funciona súper ágil, no sé cual es el motivo pero así es, de repente alguien que tenga más experiencia puede explicarlo mejor. Solo por curiosidad como creas las tablas, primero diseñas todo en el motor o dejás que Clarion cree las tablas ?
Saludos !


Arriba
 Perfil Email  
 
NotaPublicado: Lun Oct 23, 2017 12:10 pm 
Desconectado

Registrado: Mar Mar 01, 2011 8:36 pm
Mensajes: 109
Hola Martin!

Por una cuestión de tiempo, dejé todo como estaba, es decir, las tablas creadas en el DCT de Clarion y también uso el FM3 de Capesoft. Como no he probado con otros motores no sé si es algo inherente al motor, pero como vos decís, estaría bueno que alguien con más conocimiento de FireBird nos pueda contar sus experiencias.


Arriba
 Perfil Email  
 
NotaPublicado: Mar Oct 24, 2017 6:26 am 
Desconectado
Avatar de Usuario

Registrado: Dom Feb 06, 2011 9:34 am
Mensajes: 1013
Ubicación: España
No uso Firebird así que mis respuestas van más orientadas a MS SQL aunque en definitiva más o menos deberían poder aplicarse. Mencionaste que con 20000 registros se hace lento, esa cantidad el motor lo debería poder manejar sin problemas. Lo primero que haría sería revisar los índices. Tené en cuenta que no hace falta que en SQL tengas exactamente los mismos índices que definiste en el motor pero sí es importante tener los necesarios. Eso no implica crear un índice por cada campo, lo mejor, en este caso, es hacer un trace y ver qué le está enviando Clarion al motor (o un Profiler en SQL) y luego analizar la consulta en sí misma. En MSSQL existen los planes de ejecución y es muy importante saber leerlos porque es una de las formas de empezar a hacer tunning.
Luego, aún cuando los browses de Clarion funcionan bien con TPS, no es lo mismo con SQL. Aquí hay que evitar el tráfico al motor, evitar traer registros que no se necesitan. Por ejemplo, en el caso de un browse de facturas, necesitamos traer todas? No sería más óptimo, por ejemplo, limitar el browse a las últimas 100 facturas y poner un filtro, por ejemplo, que el usuario pueda modificar? Supongamos que tenemos un campo fecha, DESDE/HASTA, cuando abrís el browse lo hacés seteando los últimos 15 días y si el usuario tiene que consultar algo anterior, que ponga la fecha o el cliente que quiere consultar.
Los locators incrementales, en SQL, son malos. De nuevo, supongamos que tenemos una tabla con 10.000 artículos. Presionamos la letra B, Clarion envía al motor: traeme todos los artículos que empiecen con B (y son, digamos, 500). Luego presionamos la "a", de nuevo, Clarion va al motor y le dice: ahora traeme todos los que empiecen con Ba (ahora son 100). Luego la "r" y así sucesivamente. En lugar de eso, el locator lo remplazás por un Entry, el usuario entra "Bar" y Clarion va al motor UNA SOLA VEZ y le dice: traeme todo lo que empieza con Bar (y tal vez sean solo 20). Lo más probable a esta altura es que tu usuario te diga "ehhh!!! antes yo apretaba una tecla y ya me aparecían las cosas!!!" y ahí es cuando lo tenés que convencer que ahora es mejor :).
Siguiendo con el mismo ejemplo, supongamos que no tenés un índice por el campo que estás buscando, eso obligaría a SQL a hacer un scan de la tabla, recorriendo registro por registro seleccionando los que cumplan la condición, algo nada óptimo.
Al margen de esto: por qué Firebird? No digo que sea malo, de hecho se usa y mucho pero MSSQL tiene la versión Express que está más que bien para empresas pequeñas y medianas. Y para el desarrollador está la versión Developer que tiene las mismas funciones que la Enterprise (no se puede usar para sistemas comerciales) y está más que bien.
Si tenés algún problema, no dudes en consultarme por aquí o privado.

_________________
Mauricio, básicamente usando Clarion 6.3
www.tdcsoftware.com y www.clarioneros.com/blog


Arriba
 Perfil Email  
 
NotaPublicado: Mar Oct 24, 2017 6:28 am 
Desconectado
Avatar de Usuario

Registrado: Dom Feb 06, 2011 9:34 am
Mensajes: 1013
Ubicación: España
Algo que olvidé mencionar: dónde están definidas las relaciones? En el DCT? Si es así, sacálas urgentemente y que las maneje el SQL. En el dct les ponés Cascade (Server) o Restrict (Server). Clarion hace cursores en los updates en cascada, por ejemplo, y eso "mata" al motor.

_________________
Mauricio, básicamente usando Clarion 6.3
www.tdcsoftware.com y www.clarioneros.com/blog


Arriba
 Perfil Email  
 
NotaPublicado: Jue Oct 26, 2017 6:28 pm 
Desconectado

Registrado: Lun Feb 07, 2011 1:29 pm
Mensajes: 63
Hola Duenda

Más allá de todo lo que te comenta Mauricio, el problema que más me afectó la velocidad de los browses al migrar a Firebird fue que fui migrando de a poco algunas tablas. En los browses de las tablas Firebird que estaban relacionados con una tabla tps la velocidad era espantosa. Después de renegar bastante encontré que lo que degradaba la velocidad era tener la tabla relacionada en la File-Browsing list box. Tuve que sacarla y hacer la lectura del archivo relacionado en SetQueueRecord.

También me presentó lentidud en la secuencia loop>next. Para no migrarlo a código sql, podés mejorarlo utilizando mitabla{prop:sql} = '...... eliminando el set. También con mitabla{Prop:Where}=

Sds
Manuel


Arriba
 Perfil Email  
 
NotaPublicado: Jue Oct 26, 2017 6:28 pm 
Desconectado

Registrado: Lun Feb 07, 2011 1:29 pm
Mensajes: 63
Hola Duenda

Más allá de todo lo que te comenta Mauricio, el problema que más me afectó la velocidad de los browses al migrar a Firebird fue que fui migrando de a poco algunas tablas. En los browses de las tablas Firebird que estaban relacionados con una tabla tps la velocidad era espantosa. Después de renegar bastante encontré que lo que degradaba la velocidad era tener la tabla relacionada en la File-Browsing list box. Tuve que sacarla y hacer la lectura del archivo relacionado en SetQueueRecord.

También me presentó lentidud en la secuencia loop>next. Para no migrarlo a código sql, podés mejorarlo utilizando mitabla{prop:sql} = '...... eliminando el set. También con mitabla{Prop:Where}=

Sds
Manuel


Arriba
 Perfil Email  
 
Mostrar mensajes previos:  Ordenar por  
Nuevo tema Responder al tema  [ 7 mensajes ] 

Todos los horarios son UTC


¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado


No puede abrir nuevos temas en este Foro
No puede responder a temas en este Foro
No puede editar sus mensajes en este Foro
No puede borrar sus mensajes en este Foro
No puede enviar adjuntos en este Foro

Saltar a:  
Powered by phpBB® Forum Software © phpBB Group
Traducción al español por Huan Manwë para phpbb-es.com