Se pierden transacciones

Gracias por la respuesta. Efectivamente llamamos a un
procedimiento, pero dentro del cual no se realiza ninguna
instruccion COMMIT ni ROLLBACK.

Antes he olvidado de comentar que la parte que no se
ejecuta de la transacción és precisamente la primera.
Parece que "alguien" realizara un rollback.

También debería haber comentado que las transacciones son
excepcionalmente largas, pero en este caso es inevitable.

Por último, hemos detectado también que el problema se
produce siempre cuando hay mucha carga en el SQLSERVER
(bloqueos, etc...). Mi sospecha inicial era que el
SQLSERVER al detectar un problema (deadlock, ..o alguna
cosa así) realiza un ROLLBACK sin notificar a nuestro
programa la excepcion producida, con lo cual a la
siguiente instruccion SQL se inicia una transaccion
implícita que acaba normalmente con un COMMIT.

¿podría ser que las excepciones ocurridas dentro de un
procedimiento no notificaran al programa que se han
producido?

¿cómo podríamos controlar que al realizar nuestro commit
estamos realmente en la misma transacción?


Grácias

Hola:
La variable @@TRANCOUNT te indica el nivel de anidamiento de las
transaccion de manera que cada BEGIN TRAN le suma uno y cada COMMIT le resta
uno. Revisa el varlor. El ROLLBACK cancela todos.
Adicionalmente revisa los Triggers ya que un mal manejo de transacciones
en estos produce problemas de este tipo. Revisa que en caso de errores se
hga tanto ROLLBACK como RAISERROR y que los procedimientos revisen el
control de errores @@Error inmediatamente despues de hacer el
INSERT/UPDATE/DELETE.
Podrias usar el Profiler para capturar las sentencias que se enviaron al
servidor y revisar luego en una maquina de pruebas, lo que esta ocurriendo.
Por ultimo puede servirte un procedimiento que existe en
http://www.configuracionesintegrale...p?articulo!7
Para monitorear una tabla.
Suerte,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda


"albert" wrote in message
news:4bc701c490da$b8846090$
Gracias por la respuesta. Efectivamente llamamos a un
procedimiento, pero dentro del cual no se realiza ninguna
instruccion COMMIT ni ROLLBACK.

Antes he olvidado de comentar que la parte que no se
ejecuta de la transacción és precisamente la primera.
Parece que "alguien" realizara un rollback.

También debería haber comentado que las transacciones son
excepcionalmente largas, pero en este caso es inevitable.

Por último, hemos detectado también que el problema se
produce siempre cuando hay mucha carga en el SQLSERVER
(bloqueos, etc...). Mi sospecha inicial era que el
SQLSERVER al detectar un problema (deadlock, ..o alguna
cosa así) realiza un ROLLBACK sin notificar a nuestro
programa la excepcion producida, con lo cual a la
siguiente instruccion SQL se inicia una transaccion
implícita que acaba normalmente con un COMMIT.

¿podría ser que las excepciones ocurridas dentro de un
procedimiento no notificaran al programa que se han
producido?

¿cómo podríamos controlar que al realizar nuestro commit
estamos realmente en la misma transacción?


Grácias

Verifica si las tablas afectadas en la transaccion tienen
triggers/desencadenadores. En los cursos que doy tengo un ejemplo tipico de
un trigger que hace un rollback de una transaccion implicita sin que la
misma genere un error que llega al usuario o al SP que lo invoca.
Si dentro del codigo de un trigger haces un ROLLBACK sin reakizar un
RAISERROR se genera la situacion que planteas.

Saludos
Adrian D. Garcia
MCSD
NDSoft Consultoria y Desarrollo

"albert" wrote in message
news:4bc701c490da$b8846090$
Gracias por la respuesta. Efectivamente llamamos a un
procedimiento, pero dentro del cual no se realiza ninguna
instruccion COMMIT ni ROLLBACK.

Antes he olvidado de comentar que la parte que no se
ejecuta de la transacción és precisamente la primera.
Parece que "alguien" realizara un rollback.

También debería haber comentado que las transacciones son
excepcionalmente largas, pero en este caso es inevitable.

Por último, hemos detectado también que el problema se
produce siempre cuando hay mucha carga en el SQLSERVER
(bloqueos, etc...). Mi sospecha inicial era que el
SQLSERVER al detectar un problema (deadlock, ..o alguna
cosa así) realiza un ROLLBACK sin notificar a nuestro
programa la excepcion producida, con lo cual a la
siguiente instruccion SQL se inicia una transaccion
implícita que acaba normalmente con un COMMIT.

¿podría ser que las excepciones ocurridas dentro de un
procedimiento no notificaran al programa que se han
producido?

¿cómo podríamos controlar que al realizar nuestro commit
estamos realmente en la misma transacción?


Grácias