Capturar Mensajes de triggers


([N3] blanyi) #1

Hola buenos días.

Teniendo en cuenta la recomendación de que lo que tenga que ver datos es mejor tenerlo en la base de datos, he querido crear procesos, funciones o eventos de tabla para controlar algunas cosas.

Cuando programo un evento de tabla para restringir la creación o modificación de un registro, el programa detiene el proceso y el alta o la modificación no sigue. El usuario final no recibe ningún mensaje o recibe un mensaje tipo “Error al dar alta la ficha” o “Error al modificación de ficha”, es decir se queda sin saber exactamente cuál es la razón por la que el proceso no le deja avanzar".

Mi pregunta es: ¿hay alguna manera de capturar un código de error en la interfaz para presentarle al usuario final un mensaje más diciente?

Sino es así no le veo ningún sentido al programar restricciones en la base de datos si para poder presentar mensaje al usaurio luego tengo que implementar las mismas restricciones en la interfaz, es decir en la caja de aplicación.

Cordial saludo.

YIMY MORA ACONCHA


([N1] wikan) #2

Buenas,
cuando se dice que todo lo que tenga que ver con datos en el proyecto de datos, es una guía. Es decir, procesos que modifiquen listas o hagan grandes cambios siempre mejor en le servidor, búsquedas, etc.

Pero todo lo que tenga que ver con interfaz, tendrá que ir el cliente. Por decirlo de otra manera, en el proyecto de aplicación. Normamente, las comprobaciones de campos vacíos, campos duplicados, etc. para poder mostrarlos al usuario deben ir en el propio formulario.

En los triggers, en mi caso por ejemplo, controlo cambios de maestros que afecten a los plurales, campos vacíos que la propia aplicación debe rellenar si están vacíos. Pero las restricciones siempre las pongo en el cliente.

Piensa que tu eres el administrador de la base de datos y en un momento dado necesitas crear un registro y debes “saltarte” alguna. Si lo pones en un trigger tu mismo te estarás bloqueado.


([N3] blanyi) #3

Gracias Manuel por tu respuesta.

Aunque no estoy de acuerdo en todo lo que dices porque es bueno poder aplicar restricciones a nivel de la base de datos, eso nos ayuda a mantener mejor la integridad de los mismos, pero pienso que sería mejor aun si se pudieran personalizar los mensaje que se pudieran mandar para indicar con un aviso claro para el usuario final para que el sepa cual regla está violando.

Lo digo porque con otras bases de datos se puede hacer esto que comento.

De todos modos te reitero mis agradecimientos por tomar el interés en contestar.

YIMY MORA ACONCHA


([N3] pacosatu) #4

Hola YIMY.

Tenemos que adaptarnos a la herramienta de desarrollo que tenemos y olvidarnos de las posibilidades de otros entornos. En mi opinión un gran error de Velneo comercialmente es intentar compararse con monstruos tecnológicos como SQLServer u Oracle. Cuando has utilizado estas herramientas para desarrollo es dificil no acordarse de ellas cuando recibes un escueto mensaje de error de Velneo que dice “Error de alta”. Vas a mirar el log de VAdmin y la cosa no mejora en absoluto.
Otro tema muy distinto es comparar Velneo en temas de rapidez de gestión de transacciones.

Mi sensación con Velneo es que se diseñó pensando que solo era necesario construir las tablas, establecer las relaciones permanentes en la base de datos, definir las actualizaciones y triggers, crear los formularios con las Rejillas y botones y que todo funcionaría como un reloj. Evidentemente esto no es así y siempre necesitaremos un buen depurador de código y un completísimo gestor de errores.

Mientras tanto, y para el lado cliente, puedes votar la Idea https://velneo.zendesk.com/entries/27962956-Eventos-Aceptar-Cancelar-y-Eliminar-del-formulario a ver si la ponen en el Horno.

Para saltarse las restricciones de los Triggers en un momento dado (labores de mantenimiento), debido a que no tenemos un comando Disable Trigger, puedes condicionar su ejecución al valor de una Variable Local de la Tabla o una Variable Global en 3P. Para los mensajes de error desde los Triggers tendrás que diseñarte tu propio sistema de gestión de Errores mediante una tabla Log en disco o devolviendo el error de la última operación en una Variable global en 3P exclusiva del Usuario conectado.

Para el lado Cliente tenemos el objeto VRegister del API donde tenemos acceso a un pseudo Diccionario de Datos, al Nº de error, al Mensaje de error de la última operación, etc… Mediante el objeto VRegister es fácil crear la capa de Lógica de Negocio y separar la capa de Interfaz de la capa de Datos manteniendo un control total de lo que estamos haciendo.
Meter toda la lógica de la Aplicación (triggers, actualizaciones, …) en las tablas de Velneo está muy bien en la teoría, pero a ver quién mantiene eso a medio plazo si no los has documentado muy bien.
A veces nos olvidamos que desde los triggers podemos ejecutar funciones y procesos del proyecto de datos y heredados. Si ponemos el código de la lógica de negocio en estos elementos luego será más fácil mantener la Aplicación.

Conclusión, ¿Quién ha dicho que Velneo está maduro?

Saludos
Paco Satué


([N4] ns) #5

Hola a todos,

Paco acabo de votar la Idea ya que creo que es interesante y nos dará un poco mas de control.

Me uno al respecto de las quejas de VAdmin y sus mensajes que son totalmente jeroglíficos, no identifican ni quien hace, ni donde hace…

Por si alguien tiene dudas de lo que estamos hablando, adjunto una captura de pantalla de uno de nuestros clientes. Valorad vosotros mismos…

Falta ver si la en la nueva versión se avanza algo al respecto y se facilita la vida al programador que al fin y al cabo es el usuario de Velneo y según tengo entendido la nueva versión va mas orientada a eso, el programador.

Saludos,
Santiago.



([N3] blanyi) #6

Gracias Paco por tu respuesta.
Ya vote tu excelente idea, ojala otros las apoyen también.

YIMY MORA ACONCHA