INFORMACION Sobre PROBLEMA GORDO con Submaestros


([N4] info) #1

Hola:
He detectado el siguiente problema, que a mi me impide seguir con v78
Cuando tenemos una tabla que es submaestra de otra submaestra sucede lo siguiente:
para ello un ejemplo:
Tabla paises
Tabla Ciudades (sub,aestra de paises)
Tabla Hoteles (submaestra de ciudades)
Tengo un formulario de paises, en el una rejilla del plural (ciudades)
pincho en la rejilla y creo una ciudad de un pais
hasta aquí todo bien (la tabla de paises es maestra)
Ahora estoy dentro del formulario de ciudades, tengo unas rejilla del plural hoteles
pincho en la rejilla y trato de crear un hotel en la ciudad
!!!Es imposible!!!
En V7.8 se ha dejado de resolver correctamente el maestro
Esto llevarlo a las lineas de un albaran, factura o cualquiera que dependa dee otro submaestro
Es imposible crear el registro

Asi que quien utilice esto que se ande al loro

A mi el tema me parece MUY pero MUY DELICADO

esto obligaria a crear dar valor a una variable en el formulario padre y rersolver en el inicio del formulario del submaestro
con el valor del maestro adecuado
o sea modificar la programacion

un saludo
Miguel


([N4] agonzalez.velneo.com) #2

Hola Miguel,

Entiendo tu preocupación ya que para quien utilice tablas submaestras habitualmente puede ser un grave problema.

Decirte que existe otra forma mucho más sencilla de poder solventar esta incidencia, además de inducir los valores por proceso utilizando variables u otros métodos.

Lo que tienes que hacer es establecer contenidos iniciales a los campos enlazados en la tabla submaestra de 2º nivel y sucesivas.

En tu caso los contenidos de los campos de la tabla Hoteles deberían ser:
Países = #CIUDADES.PAISES.ID
Ciudades = #CIUDADES.ID

De esta forma ya tendrás solucionado el problema y podrás aprovechar todas las mejoras y novedades de la versión Velneo V7 7.8

Muchas gracias por tu colaboración.

Un saludo,
Alejandro G.


([N4] ffgenoves) #3

Hola Miguel,

Efectivamente acabo de comprobar que lo que dices es cierto, lo que me sorpendre mucho es la respuesta, si esto estaba funcionando debe seguir funcionando sin que tenga que cambiar las 30 tablas que tienen el problema.

Saludos.


([N4] agonzalez.velneo.com) #4

Hola programacion.sesderma,

Discúlpame ya que quizás me haya explicado mal.
Esta incidencia es un Bug de la plataforma y en el departamento de conocimiento hemos creado el ticket correspondiente en el sistema de incidencias vBugman.
También hemos trasladado el tema y su importancia al departamento de desarrollo, para que le den solución lo antes posible.

La solución que le he indicado a Miguel, es temporal y para que la pueda aplicar ahora mismo por si desea continuar utilizando la Versión Velneo V7 7.8 hoy mismo y no tener que esperar a una posible revisión.

Un saludo,
Alejandro G.


([N3] ereitmann) #5

Hola, no seria mejor... y dado por los problemas que se estan viendo en este foro, como este, sumado al probelma de la lentitud informado en este foro por mdelgado.dinacom... recomendar que todavia no se instale la version 7.8... por que la verdad me da miedo...


([N3] entelio) #6

La solución propuesta, entiendo que vale para, siguiendo el ejemplo, poder dar de alta un hotel desde la ficha de una ciudad.

Pero me parece que el problema de los submaestros afecta a más cosas: nosotros tenemos, para hacer pruebas con V7, todas las tablas de documentos, como submaestros de una serie de tablas básicas: Empresa->Serie->Ejercicio. Pretendemos que el ID sea automático, para llevar una numeración para cada combinación empresa-serie-ejercicio

En 7.8, no me deja aceptar ningún documento, aún habiéndolo asociado a empresa, serie y ejercicio (incluso dándole valor al campo id manualmente). Da un error de código erróneo. Como a los demás, en 7.7 sí funcionaba.


([N4] innovadb) #7

Sin entrar a valorar la gravedad del asunto, mi opinión es que no deberíais usar nunca tablas submaestras, ya que estas a simple vista facilitan la programación, pero a largo plazo te mantienen demasiado atado a esa estructura y complican los procesos, búsquedas etc...

Simplemente con añadir en la tabla maestra un enlace singular de plural y en la histórica un campo numérico con contenido inicial, tendréis una estructura mucho mas flexible a largo plazo.

Un saludo


([N3] Juanjo) #8

Hola a todos:

Yo igual si entro a valorar la gravedad del asunto.

De momento parece ser que no es apropiado usar variables globales por lentitud, etc.. Si existen, que las mejore Velneo o de lo contrario que las eliminen para no liar al personal.

Ahora parece que tampoco es apropiado utilizar tablas submaestras. SI existen, que las mejore Velneo, o de lo contrario que las eliminen para no liar al personal.

Lo que existe, debe estar cribado/probado/testeado/etc al 100%.
Y si da problemas, mejor que no lo incluyan y dejamos de probar tonterías que al final nos roba tiempo.

¿ Que componente será el siguiente candidato a no utilizar ?
¿ Tablas maestras ?
Pues nos quedaremos con las estáticas.

Un saludo, Juanjo.


([N1] Emanuel) #9

Yo también no uso tablas submaestras.
Y se ve que el departamento de desarrollo y los tester no usan mucha las tablas submaestras. Jamás apareció éste problema al hacer unas cuantas pruebitas al V 7.8?

Muy bien por el departamento de Conocimiento de Velneo que da respuestas en forma muy rápida. Sigue "flojo" el departamento de desarrollo y tester por lo que veo.

Saludos.




([N4] ffgenoves) #10

Gracias Alejandro por tu aclaración, vuelvo a repetir me había sorprendido la respuesta. Estoy convencido de que el departamento de desarrollo resolvera el problema en un tiempo mas que razonable.

Saludos.


([N4] info) #11

Hola de Nuevo:
Desde luego hay que valorar lo que comenta innovadb, pero creo que a continuación de....
Pero quiero comentar algo más que no se si está relacionado
En principio me dio un problema con los tubos de ficha, de manera similar a esto, al crear una ficha con un tubo submaestro de submaestro tampoco funcionaba correctamente es decir tampoco da de alta la ficha. En este caso he de decir que el servicio de soporte me indico como arreglarlo en realidad hay que cambiar el orden delo campos maestros, pero como eran 2 tablas no me preocupo demasiado, pero por lo que veo y parece son los objetos los que inducen mal, no solo la rejilla, pero no tengo ni idea claro, en fin..
un saludo
Miguel


([N4] agonzalez.velneo.com) #12

Hola a todos,

@ entelio, te recomiendo que consultes esta incidencia en soporte. Si te es posible envía una instalación de ejemplo solo con los objetos y datos necesarios. Además explica los pasos que hay que seguir para reproducir el problema. De esta forma podremos analizar tu caso concreto y ofrecerte la mejor solución.

Gracias a todos por vuestros comentarios y paciencia.

Un saludo,
Alejandro G.


([N4] mittosoftware) #13

Concuerdo totalmente con lo que dice innovaDB, ese tipo de atajos a la larga cuesta mucho mas que el 'ahorro' de tiempo. En ese sentido, opino Velneo no debería dar soporte a ese tipo de características, para forzar a los desarrolladores a utilizar principios óptimos de diseño.
.
Esto lo sugeriría como política, no dedicarle horas-hombre a sacar características de este estilo (máxime cuando hay características tan necesarias en lista de espera, por ejemplo, un parser-generador de XML/JSON), que permiten disimular erradas prácticas de desarrollo de software en aras de 'ahorros' de tiempo a corto plazo, que pueden (y las mas veces lo hacen) derivar en problemas mas fuertes a largo plazo, o en inflexibilidad de tu desarrollo (modificaciones o adiciones de nuevas características).


([N4] info) #14

Hola de Nuevo
@cjribera, sin entrar a discutir el comentario de Innobadb que como he comentado antes, desde luego que es para valorarlo, y asi lo voy a hacer. Creo que estamos en otra cosa
1 Creo que los submaestros son muy utilies en muchas ocasiones independientemente, que con un poquito de programación mas no tengas que utilizarlos. pero como tu dices "En ese sentido, opino Velneo no debería dar soporte a ese tipo de características, para forzar a los desarrolladores a utilizar principios óptimos de diseño.
"
Pues entonces que los quiten, que digan que son una castaña , que no tenemos ni idea y que programar asi es como dices "permiten disimular erradas prácticas de desarrollo de software en aras de 'ahorros' de tiempo a corto plazo" y asi todos salimos ganando
2 No y repito No se puede decir/hacer/et... que como eso no es una forma !!muy correcta!! de programar, pues a tomar por saco que no den mantenimiento y que se rehagan los programas de algo que lleva funcionando desde siempre, que yo recuerde en Velneo/Velazquez
3 Quien lo tenga programado de otra manera pues muy bien y me alegro sinceramente por ellos, pero lo que esta programado así que haces ¿te lo comes y lo rehaces? A lo mejor es mejor al final, francamente no se

¿y los tubos de ficha, probablemente el problema viene del mismo sitio, tambien dejamos de utilizarlos?

En definitiva que hay que arreglarlo, pero ya

y luego un hilo o no se que de tecnicas aconsejables de programación en Velneo pues tambien porque no

un saludo
Miguel


([N4] agonzalez.velneo.com) #15

Hola a todos

En referencia a esta incidencia me gustaría indicar que ya se ha detectado y el equipo de desarrollo esta trabajando en la solución para incluirla en la revisión que saldrá en breve.

Un saludo y muchas gracias a todos por vuestra colaboración
Alejandro G.


([N4] mittosoftware) #16

@info.ciberideas. Yo me refería a que CONCEPTUALMENTE este tipo de prácticas no debería estar soportada. Si ya hay clientes embarcados así y con el problema quemando, es obvio que no quedará otra opción que gastar valiosos horas/hombre del equipo de I+D, para subsanarlos, cuando es un problema que no debió existir jamás, al no existir la mentada característica.
.
El tema es que de entrada se desincentiven este tipo de prácticas. Y en desarrollo de software no siempre se cumple la subjetividad de 'para gustos hay colores', si se trata de una interfaz de usuario si, pero a nivel toma de requerimientos, de análisis, de diseño de una base de datos, o de elaboración de reglas de conocimiento, si que hay principios muy sólidos que deben respetarse, para algo existen la Ingeniería de Software, las formas normales, los principios de Agile Programming, el UML, etc.
.
La posición de un fabricante debería ser, en caso de clientes que piden una característica para dar soporte a estos atajos, remitirlos a la documentación de referencia para que se ajusten a los principios correctos en Desarrollo de Software. Ojo, estoy hablando como principio, de una política PREVENTIVA.
.
Y por ultimo, a no ser que tu diseño implique cientos de tablas y miles de implementaciones ya funcionando, lo mas probable es que a la larga, es mejor reconstruir del todo las secciones construidas con parches. En el largo plazo, saldrás ganando, cuando la experiencia te compruebe como es de mas fácil modificar o ampliar un sistema donde se han cumplido lo mas estrictamente posible los mejores principios del desarrollo de software.