Viendo 4 entradas - de la 1 a la 4 (de un total de 4)
  • Autor
    Entradas
  • #31458
    Carranza Carlos
    Participante

    1)La lista de campos devueltos en una validación de tabla (tabledir + validación) puede variar de un registro a otro (dando de alta), si en el registro anterior se eligió un valor (acepta null). Esta lista no se actualiza automáticamente (no ejecuta de nuevo la sentencia sql). Cómo puedo hacer para que al abrir la pantalla ó moverse de un registro a otro, esta validación se vuelva a ejecutar?
    2) Cómo hacer para evitar más de 1 registro en una pantalla entre 2 tablas relacionadas? (1 sólo registro hijo, deacuerdo a determinadas características)
    Desde ya gracias.

    #34752
    Javier Ader
    Participante

    Buenas. El punto 1, no te termino de comprender, pero supongo que es asi:
    1) campo 1: digamos que podes elegir A o B
    2) campo 2: tiene un filtro relacionado con un tabla pero dependiente de si en el campo anterior se escogio A o B (por ej, suponiendo que la tabla con el filtro sea la de articulos: “si se escogio A, que solo se puede seleccionar Productos, si selecciono B, solo Servicios”)

    Es asi más o menos la idea? En ese caso, supongo que en el filtro estas referenciando a variables de ambiente y que no hay forma de autoamticamente obligar a recalcular la validación. Lo unico que se me ocurre es poner un callout en el campo 1 y en caso de modificarse este valor simplemente “borrar” el campo 2 (otra forma un poco más compleja es simular la validación desde el callout y solo “borrar” en caso de que no pase la validación el valor actual en el campo 2).

    En cuanto al punto 2, creo que libertya, para lograr este funcionamiento (relación 1 a 1) requiere ciertas restricciones a nivel de base de datos. La tabla “hija” tiene que tener por un lado la misma clave que la tabla padre y ademas tiene que ser una clave foranea a esta última. Estas restricciones se tienen que dar no solo a nivel de base de datos si no también a nivel de diccionario. Exactamente como se tiene que dar no lo tengo presente pero podes mirar las tablas AD_OrgInfo o AD_ClientInfo (estas son las tablas que te aparecen en la segunda solapa de Organización y de Empresa; estas solapas te permiten agregar a solo sumo una sola fila “hija”).

    #34754
    Carranza Carlos
    Participante

    Primero que nada : Muchas gracias por contestar y perdón por explicar indebidamente. Tu respuesta está clara pero no es lo que busco. A ver si esta vez me sale bien.
    1) Tengo una columna tipo tabledir, con una validación para que no traiga todos los registros, sino sólo los no utilizados (validación = campo not in (select campo where campo_con_dato_que_indica_utilizado is not NULL).
    Este valor puede o no ser seleccionado en un alta o modificación de registro.
    Si estoy haciendo un alta y selecciono un campo de la tabla secundaria, ese registro pasará a estar utilizado, y por lo tanto no deberá aparecer más dentro de las posibilidades de selección.
    Si quiero agregar un nuevo registro a la tabla principal, para que esta lista se actualice debo cerrar la pantalla y abrirla de nuevo o dar nuevo registro y “actualizar” (botón derecho del mouse) en dicho campo (sino, el registro que antes elegí sigue apareciendo en la lista). Me suena a que hay que limpiar la lista de la memoria.
    2) La tabla hija puede tener más de un registro, salvo que se cumpla cierta condición de entrada de datos de la tabla padre, por lo tanto, por no ser siempre, no lo puedo manejar con relaciones de tabla, lo tengo que hacer programáticamente, y lo que me gustaría es hacer que no estuviera disponible el botón “nuevo registro”.
    Desde ya agradecido, y espero haberme podido explicar (sino podemos seguir por chat – je)
    Revisé la tabla ad_orginfo y tiene el botón de agregar registro habilitado, después de agregar una organización y es lógico, sino no tendríamos más de una organización dentro de una compañía.

    #34753
    Javier Ader
    Participante

    1) Jaja bueno, no se si te comprendo totalmente, pero si, casi seguro que el tema es libertya “cachea” los valores de las listas. Mas alla de que no estoy seguro si la validación sql es correcta (no es mas simple?: validacion = campo_con_dato_que_indica_utilizado IS NULL ), estoy casi seguro que los campos tableDir con visualización de listas desplegables se cargan al momento de apertura de la ventana; y como decis una forma de que se “recarguen” es cerrar y abrir la ventana. La otra forma que veo, de manera aun manual, pero más simple (creo que debería andar) es dar click derecho sobre el campo tableDir y darle actualizar (en la lista debería NO aparecer lo ya usados). Chequeame esto, pero estoy casi seguro que viene por este lado.
    Otra “solución” es no usar visualización de tipo “listas”, si no usar visualización “search” (búsqueda). Las diálogos de búsquedas calculan los filtros cada vez que son abiertos.
    Otra forma, un poco más compleja (y que tiene otras contras…), es setear este campo indirectamente via un proceso. El campo lo haces de solo lectura a nivel de diccionario de datos, pero agregas un campo Boton (digamos “Especifiar campo X” y un proceso asociado que que lo que hace es abrir un dialogo mostrandole las posibles valores a elegir (pero en este caso la “validación” no estaría en el diccionario de datos, si no en el código del proceso…). El proceso, luego de tomar la selección del usuario modifica la fila asociada en la base de datos con el valor apropiado. Ahora, fijate que esta solución y usar visualización “busqueda” es casi idéntica funcionalmente (y tiene otras desventajas ya que te obliga a guardar la fila antes de disparar el proceso); la única diferencia podría venir por lo visual.

    2) Por lo que se, no hay forma de especificar ese funcionamiento a nivel de diccionario de datos. Lo que estas pidiendo sería un suerte de “Logica de inserción” a nivel de tabla, en el que uno podría especificar un logica arbitraria para determinar cuando es posible agregar un fila. Si no me equivoco, estoy casi seguro que tal versatilidad no existe.
    Se me ocurre, si esta funcionalidad es muy importante, algo similar a la ultima opción que te di en el punto anterior: basicamente las filas “hijas” no las creas de manera convencional, si no mediante un proceso asociado a un campo en la tabla “padre” (la duda que se me presenta en este momento es si el diccionario de datos permite especificar la subpestaña como “no se permite inserciones”, pero si “ediciones”; si esto no existe, estas obligado a hacer la subpesataña como solo-lectura)

    Ahí te agrego a mi lista de contactos del MSN y chateamos; ando medio ocupado últimamente, pero dos por tres me libero un poco.

Viendo 4 entradas - de la 1 a la 4 (de un total de 4)
  • Debes estar registrado para responder a este debate.