Clarion - COMMIT - ROLLBACK MS-SQL Server

Hola,
tengo un problema con el LOGOUT - COMMIT - ROLLBACK con MS-SQL Server.

Cuando realiza un ROLLBACK a causa de un Error controlado, la Transacción que controlo mediante el LOGOUT previo con dos files me la aborta OK, lo mismo si al final ejecuta el COMMIT, la Transacción se lleva a cabo OK.

El problema es que, pretendía utilizar esta posibilidad, no para errores controlados, si no para cuelgues de mi aplicación por diversos motivos (que se vaya la luz, fallo de memoria, etc.), cuando el proceso se encuentra en cualquiera de los puntos de la transacción, entre el el LOGOUT y el COMMIT. O sea que no llegue a ejecutarse el COMMIT.

Tenía la idea de que al no ejecutarse el COMMIT, aunque no se ejecutara el ROLLBACK la Transacción no se llevaría a cabo. He forzado la caída de la aplicación en varios puntos del programa, antes del COMMIT, y al final el resultado es siempre el mismo, las instrucciones de Modificación (PUT, ADD, DELETE) de la Tablas/Files (indicados en el Logout) se terminan ejecutando realmente cuando aborto antes de realizar otras instrucciones de modificación y antes del COMMIT. Si es así como trabaja el COMMIT, ¿Qué sentido tiene para proteger los datos ante cualquier tipo de caída de la aplicación?

He observado que realizando una Select desde el MS- SQL Manag. Studio sobre los registros a modificar de las distintas tablas indicadas en el LOGOUT, si hago la consulta antes del COMMIT, la select se queda "colgada" hasta que o bien se realiza el COMMIT o bien "tiro" la aplicación, esto es, se observa cómo mantiene los registros bloqueados. Una vez abortada la aplicación, se muestran por fin los resultados en la Select pero lo hacen con las modificaciones de instrucciones de la Transacción ejecutadas en el fuente antes de abortar, pero que no esperaba que tuvieran efecto al no haberse llegado a ejecutar el COMMIT.

Por Casualidad deshabiltates del Global
App Settings
Encore RI code in transaccion frame
esta opcion por que si la tenes habiliatada te puede traer ese tipo de problemas

Gracias Ricardo,
he probado tu solución, he desmarcado "Enclose RI code in transaction frame" en el "File Control" de las "Global Properties" y el resultado ha sido el mismo.

Incluso he entrado en las "Indivual File Override" he accedido a los Files implicados y en "Use RI transaction frame" lo he puesto a "No".

El resultado es siempre el mismo, si aborto el proceso en cualquier punto antes del COMMIT, es como si el LOGOUT previo no existiera.

Gracias de todos modos.

Javier:

La mayoría de las bases de datos, por default operan en modo autocommit. Es decir, de forma automática, si no hay error en la transacción y esta finaliza se hacen permanentes los cambios (COMMIT) pero si hay un error entonces se revierten (ROLLBACK).

Una manera de deshabilitar el autocommit es con la declaración BEGIN TRANSACTION antes de la transacción para posteriormente tener el control con el COMMIT o ROLLBACK.

Espero haber entendido tu pregunta.

Saludos

Gracias Francisco,

Entiendo que la función del LOGOUT(<segs>,<File1>,<File2>,...) de Clarion es equivalente al BEGIN TRANSACTION de MS-SQL Server por lo que si se cuelga en el tramo entre el LOGIN y el COMMIT no deberían realizarse los cambios en la Base de Datos.

¿Si no es así, de qué otra manera, desde Clarion, debería hacer ese BEGIN TRANSACTION de modo que sólo afecte a los dos Files que necesito?

Me da que es el Driver de Clarion para MS-SQL quien bloquea las operaciones sobre la Base de Datos una vez traducidas a MS-SQL y que cuando se MS-SQL se "libera", se traga las instrucciones que ha almacenado de alguna forma, o sea, que se aplica su propio COMMIT porque sí.

He estado buscando si existe alguna instrucción SET de MS-SQL y me en encontrado con SET XACT_ABORT ON
http://msdn.microsoft.com/es-es/library/ms188792.aspx, he probado a ponerla a OFF y tampoco ha resultado.

Te copio un codigo a ver si te ayuda.

PlanillaDescuentoDetalle{PROP:SQL} = 'SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED'
PlanillaDescuentoDetalle{PROP:SQL} = 'BEGIN TRANSACTION'

COMMIT:
PlanillaDescuentoDetalle{PROP:SQL} = 'COMMIT TRANSACTION'
PlanillaDescuentoDetalle{PROP:SQL} = 'SET TRANSACTION ISOLATION LEVEL READ COMMITTED'


Saludos

Alejandro Bit Chakoch

Ok, Gracias. Era lo que quería evitar, utilizar Instrucciones de MS-SQL. Al final ha tenido que ser de esta forma y funciona estupendamente. Lo único es que no he puesto lo del SET TRANSACTION ISOLATION, ya que no me ha sido necesario, y que en caso de "Pete" de la aplicación entre el BEGIN y el COMMIT, éste se quedaría UNCOMMITED afectando a toda la BD, algo que no me interesaba.

El READ UNCOMMITED en realidad lo que hace es permitir la "lectura sucia" en el motor. Es decir que si otro proceso quiere leer alguna tabla que esta siendo escrita por el proceso transaccional, se lo permite. En mi caso estaba haciendo inserciones con IDs de registros nuevos. Como no es logico que otra estacion cambie un documento con esa ID porque esta siendo creado, les permito que lean las tablas sin problemas. Si dejas el modo READ COMMITED provocas muchos locks para encolar las transacciones una despues de la otra, esto puede colgar tus ventas mientras grabas una planilla de pagos, como en mi caso, cosa que no tiene sentido. Usando READ UNCOMMITED no tengo proteccion de que otros procesos lean los registros que estoy alterando en una transaccion, pero si tengo la proteccion de la transaccion en si misma, es decir, se hace todo o nada, y esto es lo unico que necesito en este caso.