Hola a todos.
El tema es que considero que por algo se habla en bases de datos de ABM (altas, bajas, MODIFICACIONES).
Las modificaciones no son opcionales, son inevitables, y todas esas tropecientas variables locales intermedias que supuestamente nos ahorran los tubos en el alta, las tendremos que crear igual para las modificaciones. ¿Donde esta la gran mejora en productividad entonces?
¿Es correcto que la Idea de tubos este marcada como ‘completada’ si la solución esta coja y en la práctica es casi inservible?
¿Hay que votar una nueva idea, solo para que arreglen los tubos?, ¿o una nueva para que de una vez habiliten un verdadero deep copy, que es algo demasiado BÁSICO que debería ser obligatorio y no una ‘idea’?
Se agradece cualquier comentario, especialmente de I+D de Velneo, sobre como deberíamos proceder para que esto se tome mas en serio. ¿Alguna opinión de los desarroladores?
Gracias de antemano por cualquier comentario.
Saludos
No le des más vueltas, los Tubos solo sirven para las Altas (según la ayuda) que son las operaciones mayoritarias en una Base de Datos frente a las modificaciones y bajas.
¿Donde esta la gran mejora en productividad entonces? Pues ha sido una de las mejoras, sino la única, más importante de las últimas versiones de Velneo. Ha pasado de ser una herramienta inútil a tener características acordes a la filosofía de Velneo (ejecución en todos los planos, fácil mantenimiento, paso de variables, …).
Un ejemplo de uso:
Tenemos una tabla temporal que usamos para dar de Alta un nuevo documento en la base de datos.
Esta tabla temporal contiene campos que pertenecen a varias tablas físicas.
Una vez que el usuario confirma el formulario de Alta ya es muy sencillo ejecutar una Transacción con tantos Tubos de Ficha como tablas haya que actualizar. Serán Altas en tablas maestras, maestros de extensión, históricos, …
El mantenimiento es totalmente LIS.
¿Y qué pasa con las Modificaciones de un registro con campos de otro? Pues aquí estoy de acuerdo que Velneo no está a la altura.
Recurrir a javascript está muy bien pero genera un código poco limpio y claro, dificil de depurar y poco mantenible. ¡¡OJO!! eso no es culpa de javascript sino de la pobre integración javascript/Velneo. Además Velneo no dará soporte a fallos en código javascript.
Creo que Velneo está trabajando en los Manejadores de Ficha, ya que es la solución lógica e este problema.
Necesitamos mucho más C++/Qt.
Saludos
Paco Satué
P.D. Te respondo en este hilo para no mezclar temas
@seh
Al menos en mi caso, las operaciones de modificaciones son tambien mayoritarias, y todas las variables intermedias ahorradas a la creación, igual hay q
terminarlas creando y usando.
Incluso si se fueran mas las altas, supongamos un escenario que por cada 100 altas haya 1 modificacion, aun asi hay que crear las benditas variables intermedias, incluso si es 1000 a 1 o 1000000 a 1. Ese es mi punto.
Y si de verdad estan trabajando con manejadores, yo no entiendo para que perdieron el tiempo con esto de los tubos, debieron encararlo por ese lado desde el inicio, ¿no les parece? No que ahora tenemos que esperar otros 6 mese, para ver si en Velneo 22 solucionan esto de una buena vez. Que no estamos hablando de bells and whistles, sino de algo BÁSICO, que es el deep copy.