Control de transacciones abortadas


([N4] apinna.winmotor) #1

Hola comunidad,

sigo padeciendo una carencia de v7 que teníamos en v6 : control de las transacciones del servidor. Es decir en v6 podíamos consultar el archivo de transacciones (al menos nosotros teníamos la estructura de esa tabla pasada por Velneo).

En nuestro caso nos encontramos con un problema irresoluble : en la instalación de un cliente que emite unos 15.000 albaranes al año de repente me aparecen dos que tienes el total mal acumulado, una línea en cada uno de ellos no se ha actualizado (no penséis por favor en condiciones ni nada lógico ni de programación, lo hemos revisado muy bien).

Al igual que nosotros Rafa llega a la misma conclusión : por alguna razón imposible de averiguar ahora la transacción en su momento se ha abortado, y el caso es que esto ha pasado en dos albaranes con muchas líneas cada uno.

Pues a lo que voy, que insisto en que nos es imprescindible poder acceder a un registro de transacciones, al menos de las abortadas, y que tenemos una idea en el correspondiente foro y os ruego la votéis a ver si sube y lo conseguimos :

http://velneo.zendesk.com/entries/21601291-Controlar-transacciones-abortadas

Muchas gracias a todos


([N4] mittosoftware) #2

Creo que esto está relacionado un problema que ya he planteado en su momento, en este tipo de casos de albaranes con un maestro y muchas lineas de albaran, la transacción deberia ser UNA SOLA, el albarán con todas sus líneas, al todo o nada. No una transacción separada por cada línea de albarán. Los ejemplos por defecto de Velneo deberían venir así.

Les repito un ejemplo para que se den cuenta. Se modifica un albarán de muchas líneas, y se empiezan a cambiar datos de las líneas, pero antes de confirmar todo, se decide CANCELAR la modificación del albarán. Pues se cancela, pero los cambios que se hicieron a las líneas SE MANTIENEN.

¿Que sugieren con los ejemplos actuales de Velneo, incluidas open apps como vERP?, ¿que impriman cada albarán, completo con todas sus lineas, antes de empezar a modificarlo?, y que si se cancela esa modificación, cambien a mano cada línea, una por una, para que quede como esta en la impresión que hicieron antes de iniciar los cambios?, ¿se dan cuenta de lo absurdo que suena?

Y puse ejemplo de albarán porque es lo que manejan ustedes, pero esto se da en cualquier escenario maestro-plurales. Espero se entienda mi punto.
Saludos.


([N4] apinna.winmotor) #3

@cjribera

no se trata de esto aunque pudiera tener algo que ver. Para hacer lo que dices bastaría con un byte en las líneas que indique si el documento está o no cerrado y condicione las actualizaciones.

En nuestro caso se trata de que por el motivo que indico y se puede dar en millares de casos nos es vital controlar las transacciones abortadas.


([N3] pacosatu) #4

Hola.

Es un tema interesante que está muy poco documentado.

¿Qué entiende Velneo por una Transacción abortada?

Es cierto que en todos los cursos que he visto no se trata el control de transacciones y menos la gestión de lo que ha ocurrido con el posible error de transacción. Siempre suponemos que el botón Aceptar hará lo que tiene que hacer y no es necesario el control de errores. La explicación es que las transacciones son automáticas, pero bueno, eso ocurre en todas las bases de datos de cierta índole.

Ya propuse en su día una Idea para complementar los Botones de Aceptar con eventos Pre y Post y así poder controlar errores.

No entiendo qué sentido tiene saber que se ha abortado una transacción si no hemos sido capaces de detectarlo en nuestro código. Una transacción abortada que se ha dado por buena en nuestro codigo va a producir una falta de integridad en nuestra base de datos que puede llegar a ser grave.

Lo de los acumulados siempre me ha parecido un tema dificil de mantener y con vuestra experiencia mis dudas se ven confirmadas.

En cuanto al tema de poder englobar en una transacción la edición de las Líneas de una misma cabecera, yo he probado hacerlo en un formulario con Bloqueo Duro y no he recibido buenas críticas ya que puede provocar transacciones desatendidas, ¡¡tienen toda la razón!!. Me han propuesto hacerlo en una tabla temporal con la poca optimización de código que eso conlleva.

Para este caso existe una técnica que consiste en editar los registros en un bufer temporal en memoria, evitando transacciones desatendidas, controlamos oldval() y podemos deshacer los cambios sin impacto en la base de datos. Voy a madurar la Idea y la propongo.

Saludos
Paco Satué


([N4] mittosoftware) #5

@apinna.winmotor, por si acaso, lo del Byte soluciona las actualizaciones, pero no soluciona el asunto de ¿que valores tenía esa línea de albarán antes de ser modificada?

Porque incluso, si no dispara actualización, te va a parecer que hay un error de integridad.

Por ejemplo, si de un producto, tenias stock de 100 y un comprobante de salida decia que salieron 20 de ese producto.

Modificas esa linea y a 20 le pones 30, luego cancelas en el encabezado del comporbante, no hace la actualización pero queda el nuevo valor de 30, y si haces un reporte detallado del producto, te aparecerá como una inconsistencia.

Lo que dice Paco Satué lo he pensado, pero tendría que usarse js, porque lo que llaman ‘tubos’ no funcionan bien, y se carece de algo parecido al deep assignment, entonces usar tablas en memoria va a implicar la necesidad de js (cada vez mas usado, con lo ‘elegante’ y ‘seguro’ que es) para poder operar rápidamente entre las tablas en memoria y disco.


([N4] apinna.winmotor) #6

@cjribera y @seh

muchas gracias por vuestros comentarios, pero sinceramente, mi problema no va por ahí en absoluto. Os repaso la cuestión :

Esta base de datos ha generado en el 2013 unos 45.000 documentos de los cuales 15.000 son albaranes de ventas y de éstos 2 tienen un error en la acumulación de totales. Como entenderéis en absoluto me planteo un cambio en la forma de grabar o ejecutar las actualizaciones de las líneas, ese tema tiene muchas opciones y posibilidades y no son nuestro problema ahora mismo.

Simplemente si yo pudiera detectar y monitorizar los detalles de una transacción (quien, cuándo, haciendo qué) tendríamos una ayuda para averiguar qué ha pasado y buscar solución. Como dije esto es algo que teníamos en v6 y suponía una estupenda ayuda.

También es algo que se echa mucho de menos en desarrollo cuando se producen problemas y hay que averiguar dónde se está produciendo la colisión.

Muchas gracias por vuestros comentarios