Triggers, datasets y updates de dataadapters

ALTER TRIGGER [dbo].[TRIGGER_ACTUALIZA_FACTURA]
ON [dbo].[SQL_FACTURAS] FOR INSERT, UPDATE
AS
DECLARE @CODIGO_PROYECTO VARCHAR(7)
DECLARE @NUM_FACTURA BIGINT
DECLARE @TOTAL MONEY
DECLARE @SUMAIMPANT MONEY
DECLARE @ANYO SMALLINT
DECLARE @ANUALIDAD MONEY
DECLARE @IMPORTE_BRUTO MONEY
DECLARE @IMPORTE_INSERTED MONEY
DECLARE @IMPORTE_PENDIENTE MONEY
IF @@ROWCOUNT=0 RETURN
DECLARE CURSOR_PTES CURSOR FOR
SELECT DISTINCT ANYO, COD_PROYECTO FROM INSERTED
OPEN CURSOR_PTES
FETCH NEXT FROM CURSOR_PTES
INTO @ANYO, @CODIGO_PROYECTO
WHILE @@FETCH_STATUS=0
BEGIN
SELECT @IMPORTE_BRUTO=SUM(IMPORTE_BRUTO) FROM SQL_FACTURAS GROUP BY
ANYO, COD_PROYECTO HAVING ANYO=@ANYO AND COD_PROYECTO=@CODIGO_PROYECTO
SELECT @IMPORTE_INSERTED=SUM(IMPORTE*(1+IVA)) FROM INSERTED GROUP BY
ANYO, COD_PROYECTO HAVING ANYO=@ANYO AND COD_PROYECTO=@CODIGO_PROYECTO
SELECT @IMPORTE_PENDIENTE=IMPORTE_PTE FROM SQL_ANUALIDADES WHERE
COD_PROYECTO=@CODIGO_PROYECTO AND ANYO=@ANYO
IF @IMPORTE_PENDIENTE<@IMPORTE_BRUTO+@IMPORTE_INSERTED
BEGIN
ROLLBACK TRAN
RAISERROR('ERROR',1,1)
CLOSE CURSOR_PTES
DEALLOCATE CURSOR_PTES
RETURN
END
ELSE
BEGIN
UPDATE SQL_ANUALIDADES SET
IMPORTE_PTE=@IMPORTE_INSERTED WHERE
COD_PROYECTO=@CODIGO_PROYECTO AND ANYO=@ANYO
END
FETCH NEXT FROM CURSOR_PTES
INTO @ANYO, @CODIGO_PROYECTO
END
CLOSE CURSOR_PTES
DEALLOCATE CURSOR_PTES

/* Aquí viene el código que actualiza otros campos */

El código C# es simplemente un dataadapter.update(dataset) teniendo el
dataadapter sus comandos de inserción, actualización, borrado y
selección.

Quizás esté mal construido, hasta ahora he usado triggers en pocas
situaciones, pero me sigue llamando la atención que funcione en solo
algunas circustancias

Gracias de antemano

Saludos

Alhambra-Eidos ha escrito:

Puede usted aportar el código del trigger y el código C# que tienes para
realizar el Update ?

Pregunta tonta:
¿Realmente te hace falta el rollback dentro del procedimiento
del trigger? No hice muchas cosas con SQLServer así que no
se si es algo necesario allí. De lo que SI estoy seguro es que
no deberías tener commits.

Como norma general siempre trato de dejar el manejo de la
transacción al usuario (programador) en el nivel mas alto.
Me refiero a donde se maneja la lógica de negocio.
Además trato de evitar transacciones anidadas.

ALTER TRIGGER [dbo].[TRIGGER_ACTUALIZA_FACTURA]
ON [dbo].[SQL_FACTURAS] FOR INSERT, UPDATE
AS
...
IF @IMPORTE_PENDIENTE<@IMPORTE_BRUTO+@IMPORTE_INSERTED
BEGIN
ROLLBACK TRAN
RAISERROR('ERROR',1,1)
...

Bueno, el rollback la verdad... no creo ni que hiciera falta, porque la
propia operación, de realizarse, vulneraría una de las constraints de la
tabla de anualidades. No hay ninguna transacción explícita. Lo que debería
hacer el rollback es tirar la transacción completa de inserción o
actualización que llama al trigger (al menos eso me explicaron a mi hace
años, que puedo estar equivocado)

Respecto a manejar al nivel más alto, si te refieres al lenguaje de
programación que está sobre la BD, no es que no quiera manejar esto desde
ahí, es que además quiero que no se realicen operaciones directamente sobre
las tablas que vulneren la integridad de la base, de ahí que haya optado por
esta vía. Supongo que podría establecer ciertos permisos para esto, pero
incluso en momentos de pruebas o puntuales, yo como administrador voy a
necesitar hacer operaciones directamente sobre las tablas ( y del último en
fiarme es de mi mismo). Obviamente, no me voy a obcecar con esto porque no
creo que me compense estar días con un tema que puedo resolver de otras mil
maneras, ya sea mediante SQL con un procedimiento almacenado o mediante C#
con el código correspondiente. De todas formas, si descubro mi propio fallo
o el por qué, ya lo comentaré aquí

Gracias a todos

Saludos

"Hernan" escribió en el mensaje
news:
Pregunta tonta:
¿Realmente te hace falta el rollback dentro del procedimiento
del trigger? No hice muchas cosas con SQLServer así que no
se si es algo necesario allí. De lo que SI estoy seguro es que
no deberías tener commits.

Como norma general siempre trato de dejar el manejo de la
transacción al usuario (programador) en el nivel mas alto.
Me refiero a donde se maneja la lógica de negocio.
Además trato de evitar transacciones anidadas.

ALTER TRIGGER [dbo].[TRIGGER_ACTUALIZA_FACTURA]
ON [dbo].[SQL_FACTURAS] FOR INSERT, UPDATE
AS
...
IF @IMPORTE_PENDIENTE<@IMPORTE_BRUTO+@IMPORTE_INSERTED
BEGIN
ROLLBACK TRAN
RAISERROR('ERROR',1,1)
...

Estoy utilizando la versión gratuita de SPAMfighter para usuarios privados.
Ha eliminado 12619 correos spam hasta la fecha.
Los abonados no tienen este mensaje en sus correos.
¡Pruebe SPAMfighter gratis ya!

Si descubre algo sobre el tema ,coméntelo por favor.

http://www.alhambra-eidos.com/web2005/index.html


"Juan Diego Bueno Prieto" wrote:

Bueno, el rollback la verdad... no creo ni que hiciera falta, porque la
propia operación, de realizarse, vulneraría una de las constraints de la
tabla de anualidades. No hay ninguna transacción explícita. Lo que debería
hacer el rollback es tirar la transacción completa de inserción o
actualización que llama al trigger (al menos eso me explicaron a mi hace
años, que puedo estar equivocado)

Respecto a manejar al nivel más alto, si te refieres al lenguaje de
programación que está sobre la BD, no es que no quiera manejar esto desde
ahí, es que además quiero que no se realicen operaciones directamente sobre
las tablas que vulneren la integridad de la base, de ahí que haya optado por
esta vía. Supongo que podría establecer ciertos permisos para esto, pero
incluso en momentos de pruebas o puntuales, yo como administrador voy a
necesitar hacer operaciones directamente sobre las tablas ( y del último en
fiarme es de mi mismo). Obviamente, no me voy a obcecar con esto porque no
creo que me compense estar días con un tema que puedo resolver de otras mil
maneras, ya sea mediante SQL con un procedimiento almacenado o mediante C#
con el código correspondiente. De todas formas, si descubro mi propio fallo
o el por qué, ya lo comentaré aquí