Estoy haciendo una rejilla que muestre los trabajos realizados y por realizar. Y uno de los campos lo coloreo en funcion de si esta terminado o no (boleano) y si la fecha del trabajo es igual o mayor a la de hoy.
Son solo 7 condiciones:
Cancelado (boleano)
Sin material (boleano)
Terminado (boleano)
Pendiente (boleano)
Y tres colores segun si el trabajo tiene fecha de 1, 2 o mas de 3 dias a futuro con una condicion tal que asi (#TRABAJO-TERMINADO%=0)&(#FECHA>(addDays($FECHA_HOY@SIGEL (ERP)_DAT.dat, 3))
Pues cuando añado la condicion de las fechas noto que la rejilla se ralentiza incluso la apertura de formulario se retrasa. ¿Alguien sabe que puede ser? Si no pongo la condicion de fechas va fluido.
Por lo que ves es que en cada linea tiene que realizar el calculo antes de mostrar… por lo que podría decirse que ese es el problema de la lentitud en la carga…
Lo que podrías hacer es crear un campo formula #transcurrido, donde se establezca el valor de fhoy() - Fecha_Hoy, siendo este el resultado de hoy menos tu carga, lo que daría la cantidad de días transcurridos… y este resultado agregar en (#transcurrido> 3).
En #transcurrido puedes agregar un sentencia de tipo: SI Cancelado = 0, que realice el conteo contra fhoy(), y si esta terminado deje de contar de fhoy(), y directamente si tenes un campo #Fecha_Finalizado, que tome de alli: #Fecha_Finalizado - #Fecha_Inicio.
He realizado la prueba de poner un campo formula que me calcule los días que lleva vencido o le quedan en la tabla de trabajos…pero igualmente cuando incluyes ese campo en una condición de rejilla se vuelve a ralentizar.
Es raro lo que te ocurre.
¿Todos los campos que entran en la fórmula o condiciones de estilo son campos propios de la tabla? Es decir ¿No hay campos de tipo puntero maestro, virtual, …?
Creo que ya encontré el problema… ya me había pasado y la lentitud es por VARIABLE GLOBAL - $FECHA_HOY@SIGEL (ERP)_DAT.dat…
Prueba con un fhoy() y vas a ver la diferencia… o en todo caso, en vez de GLOBAL pasa a LOCAL, ya que eso queda en memoria…
Efectivamente ha sido quitar la variable global de la formula y dejar de fallar. La lentitud con la que Velneo trabaja las mismas es el problema de todo. Tomare nota para el futuro.
Vamos a ver, no tomes conclusiones rápidas sin analizarlas.
Las Variables Globales son una herramienta muy versátil en Velneo, porque nos permite disponer de datos globales a la aplicación. Existen 2 tipos de Variables Globales (lo que Velneo llama Persistencia), las que residen en Memoria y las que residen en Disco. Esto nos permite jugar con la visibilidad de la Variable Global, a nivel de usuario, de aplicación, de plano de ejecución, …
Este concepto de Variable Global no es exclusivo de Velneo, existe en todos entornos de programación.
En tu caso, seguramente has usado una Variable Global en disco, lo que supone que cada vez que hay que leer el valor de la Variable Global hay que realizar un acceso al servidor vServer mediante un socket y toda la secuencia correspondiente.
Sí, el valor de una Variable Global en disco se guarda en el disco del vServer, para que dicho valor sea accesible a nivel de aplicación por todos los Usuarios.
Realizar un acceso puntual a una Variable Global en disco no tiene repercusión en la experiencia de usuario, pero acceder en una Rejilla con 500 filas y sus 500 sockets abiertos para leer sendos valores remotos en disco, entonces sí que el desastre está asegurado.
Conclusión, convierte la Variable Global de disco a memoria y nos cuentas el resultado.
Efectivamente la he convertido a variable en memoria que para el caso me vale porque se inicializa cada vez que abres el programa y con eso va igual que con currentDate()