Hola, alguien sabe si esta incidencia esta resuelta: http://velneo.es/foros/topic/formulario-con-varias-rejillas
Me pasa al cargar un formulario con una rejilla que tiene 96000 registros y se tira su par de minutos (literal) cargando el formulario (esto en v6 no pasaba :) )
Vosotros como habeis solventado la lentitud al abrir un formulario con rejillas en subformularios?
Gracias
Hola,
Pues haber primerio lo primero: si necesitas 96000 en una rejilla salvo que tengas un informe o tengas una necesidad muy especifica no le veo el punto ?, en mi caso cuando abro un maestro en el que muestro alguna de sus historicos (ejm Articulos y Lineas) solo muestro los ultimo 100 o 1000 pero no toda la tabla.
Ahora suponiendo que si los necesites yo revisaría:
1. que no estes mostrando campos de punteros indirectos o de enlaces a hermanos.
2. si estan en PaaS hay que ser sensatos V7 es eficiente pero internet es internet.
3. dado el caso te tocara montarte una solucion de paginación a "pedal" como dicen.
Saludos,
Gracias Cristian, el tema de los 96000 registros es si o si, porque cuando se crean los registros toca revisarlos con filtros y demás cosas.
Probé a cambiar el cargar plurales por una busqueda y mejora mucho el rendimiento, pero aun asi el abrir el formulario aunque no tenga historicos se demora mucho (comparado con v6), a alguien mas le pasa esto?
Estoy en un server propio y no tengo punteros indirectors ni enlaces
El proyecto no tiene errores,
Soyglobales, no debería haber ninguna diferencia con 6.x, igual hay algo mas que es lo que te genera esa relentización
Pero estas cosas es importante que las reportes a Soporte, pues siempre es posible que exista algún Bug, que solo aparece con este volumen de datos. Es muy bueno para nosotros partir de esas pruebas que hacéis pues la casuistica posible es muy grande y no siempre se detecta en los test internos
En un formulario, con varios combo box, país, provincia, población, se cargan 8170 registros y tarda varios segundos en abrir el formulario, pero considero que es lógico al estar en la nube, y el problema, al menos en los combo box, es que no se pueden utilizar subíndices, así que no queda más remedio que esperar a la nueva versión, que no se sabe si ya estará implementada esta característica, si se va implementar algún día o yo que sé.
El problema de las rejillas, es que en vez de utilizar algún tipo de paginación trasparente al usuario al utilizar la barra de scroll vertical, seguramente se carguen todos los registros de una vez, y claro 96000 registros desde la nube se tiene que notar, porque los milagros no existen.
@sonovisión
Pues respecto a la subindexación, yo diría que lo que está inciiada, es la subindexación de localizadores, lo que no implica que extrapole a los combos.
Hola, imaginemos, pongo una rejilla de histórico o creo una consulta, abro el formulario o lanzo la consulta, el vserver resuelve el número de registros total, el número de registros que caben en el visor, rejilla o lo que sea (esto no se como), el número de páginas total, y me manda solo la primera página, tenemos comandos como ir a sig-pag, ant-pag, etc., seria genial, por imaginar/soñar... :-)
PD:Si ya se que podríamos crear una vclase o algo parecido, pero no habíamos quedado que Life Is Soft ?.
Saludos.
Miguel.
Hola
@Comercial.arhes2000
Ponlo en el foro de Ideas igual tenemos suerte
y....
life is life (Opus 1984)
http://www.youtube.com/watch?v=EGikhmjTSZI
salu2
Miguel
Sonovision: lo he probado contra una ficha sin historicos y va lento de igual
mperez: en soporte todavia estan mirando otra incidencia reportada
Apoyo lo del indexador automático, pero...
Cierto es que no conozco el funcionamiento de la aplicación en sí, y cada aplicación es un mundo, pero me sigue pareciendo una barbaridad cargar de golpe 96000 registros..96000 registros que el usuario no irá a revisar uno a uno, y podrías aplicar esos filtros con búsquedas en los momentos que lo necesites, yo creo..
96000 registros (de cuantos campos estamos hablando?) más cálculos, más cargas de maestros etcétera, es de cajón que vaya lento en la nube.
Quizás una tabla temporal con persistencia en memoria (que sería manejada del lado del cliente) ayudaría a optimizar la velocidad?
Yo no he notado la diferencia de rendimiento con las tablas en memoria, de todas formas cargar tantos registros de una sola vez no es muy efectivo ni práctico, si el cliente necesita localizar registros que cumplan ciertas características lo suyo sería que lo hicieses mediante una búsqueda compleja, es decir por más de un campo.
Hola soyglobales
Solo por el hecho de que en un formulario tengas rejillas de histórico puestas en el o en subformularios, al abrir el formulario carga todas ellas. Aunque estén si históricos (0 registros plurales) en la nube penaliza una pasada y nosotros hemos tenido que quitar estas rejillas, por ejemplo:
Ficha entidad con rejillas de Ped, Alb, Fac, Pedcompra, AlbCompra, FacCompra, Recibos y RecibosCompra, esto en la nube hay que quitarlo ya que el churrito del windows se pasa entre 1 y 2 seg para cargar el formulario, eso sin contar que tengas 96000 pedidos !!
Esto debería mejorar bastante. Como bien dice Miguel ten una idea.
Un saludo
Manolo Remohi
los 96000 registros:
Es una aplicacion para seo en diarios digitales, donde se hace una busqueda de las palabras clave en funcion de unos parametros, entonces, desde que se tienen los datos en bruto hasta que se definen las palabras definitvas tienes que cargarlas todas.
Cargarlos via busquedas de varios campos: la seleccion de los datos es subjetiva, luego en una busqueda se me quedarian datos fuera (ejemplo, palabras que tengan mas de 25000 busquedas mensuales, se me quedarian palabras importantes que aunque no tengan esas busquedas quiero tenerlas en pantalla para ver que hago con ellas)
vnexo:hay forma (optima) mediante eventos o similar para cargar los historicos cuando se activa la pestaña subformulario? mi idea es tener una variable visible por cada subformulario, al iniciar el formulario grande, las inicializo a -1, y cuando la pestaña gana foco cargar el historico, recalcular la rejilla y darle valor 1 a la variable del subformulario, asi no vuelvo a cargar los historicos.
Lo he intentado pero no me rula todavia, no me llevo bien con los eventos y interfaces
Jose
Hola Jose
Tienes varias alternativas:
1- Un subformulario que cargas mediante un botón. Esto es estéticamente feo y no queda integrado con la ficha maestra, ademas sale en modal y es incomodo según el uso. Eso si la rejilla no se carga hasta que no visualizas el subformulario con lo que la carga de la ficha principal es instantánea.
2- Activar la carga de las rejillas mediante botón. Queda mas elegante ya que esta todo integrado, el problema es que hay que pulsar un botón para que dispare un evento que active la pestaña (opcional) y refresque la rejilla. En los procesos de refresco de rejilla la carga de los 96000 récords esta condicionada bien a una variable global (no recomendado para nube) o bien mediante un valor en una tabla en memoria (la opción que te he pasado en la foto). Como ves el evento activa las pestañas para que el usuario note claramente que hay que cargarlas, lo importante es disparar el recalcular control habiendo puesto a 1 el valor de la variable global que elijas o bien en mi ejemplo el valor de la tabla en memoria que sea: fun:VAR_ESCRIBE_VALOR@Datos.dat("DOC-ENT-VEN", "", 1)
Como ves lo lógico seria que si la pestaña o formulario no es visible o esta desactivado que no se cargaran los registros, pero en fin.
Un saludo
Manolo
[attachment=17167,1416] [attachment=17167,1417]
Hola, y perdón por la intrusión.
.
Mi forma de plantearlo:
.
El formulario principal llevaria valores para condicionar las búsquedas del contenido de los subformularios.
.
Podeis poner campos temporales a usar para las búsquedas de historicos.
.
Los subformularios de históricos llevarian su correpondiente control objeto que ejecutaria un proceso.
.
La condicion de ejecucion del subformulario se podria poner para cuando coja el foco, por ejemplo. De esta forma creo que no se disparan las balas contenidas en el control. Si lo hace, bastaria con controlar la variable (a crear) para controlarlo.
.
El proceso (asignado a cada control para los historicos ) realiza la busqueda con los parametros del formulario principal condicionado.
.
Asi se ejecuta o no dependiendo de la variable con la que controlamos la ejecución.
.
De esta forma, claro; se ejecutan todos los subformularios pero no los procesos que se disparan, ya que dependerá del estado del foco o la variable que controla esto en los procesos.
.
Vamos que la búsqueda y retorno de lista de registros a la salida se ejecutará cuando verdaderamente hace falta que lo haga.
.
Ojo con la visibilidad de los subformularios, estos dependen siempre de contenidos del formulario principal.
.
.
.
saludos
Antonio Vela
http://www.velavisual.com
Gracias Vnexo, basando en tu ejemplo creo que empezare creando campos en la tabla maestro que para que no cargue historicos vacios, asi ganare algo de tiempo de carga.
Cuando volveran los gana foco a los subformularios?
soyglobales@
Yo cargaría la rejilla vacía y haría la búsqueda con variables locales. Puedes ver un ejemplo en Optimizando rejillas
Nacho
Me parece que todos los comentarios van en torno a lo que podemos hacer como programadores, que no deja de ser importante, pero esto limita las posibilidades de uso de la herramienta, si ya no uso esto o lo otro, no podernos destrozar los índices o subíndices, por ejemplo, con tal que un rejilla o informe valla mas rápido.
Pienso que la factura va en su gran parte para Velneo, que son los deben mejorar la herramienta, he probado otros productos que van desde un simple Access hasta SQL y la verdad es que dejan muy mal a Velneo cuando se trata de consultar o filtrar grandes cantidades de registros.
Recuerdo que cuando me “predicaron” de Velno, hablaron de un gran rendimiento.
Un saludo a todos.
Hola Javier.
Hay que tener claro que no podemos comparar Velneo (lo que ellos llaman Base de datos Real) con Access (Motor Jet) y SQl (SGBDR). Son tecnologías totalmente distintas.
Velneo solo puede hacer consultas de una sola tabla (Cargar lista) y no existe el concepto de consultas multitabla usando JOIN’s.
En cuanto a la rapidez de descarga, el protocolo VATP sobre el puerto estandar 690 es realmente efectivo, dentro de poco incluso encriptado en SSL. La caché en el cliente y el refresco terciario provocan la sensación de que estamos editando la tabla directamente en el servidor incluso en cloud. Esto no existe en otros entornos.
La base de Datos Real nos obliga a diseñar todos los JOIN’s de forma permanente entre las tablas del modelo relacional y aunque es cierto que cuesta acostumbrarse, a la larga es realmente eficaz.
La consulta Cargar lista simplemente carga los identificadores de las filas. Cuando el usuario reclama una ficha concreta, se consulta ésta a la caché y si no está al servidor. Los campos de la ficha se descargan al cliente junto con todos los punteros a maestro y plurales (JOIN’s), disponibles inmediatamente para el desarrollador.
Hay que reconocer que habrá mejores sistemas de consultar datos, pero éste es muy bueno.
Saludos
Paco Satué