Trigger Remoto y GOTO

yo lo veo bien , lo que no se si el error por ej en lugar de ser por culpa
del servidor que no esta es por otra cosa como lo identificas no?


Ahora al existir un error y pasar los datos a una tabla alterna, esto no te
trae problemas digo?

porque la otra tabla del servidor que se cayo por ej te quedara sin datos,
excepto que hagas algo que intente pasar los datos de esta tabla temporal a
la del servidor o algo asi, me explico?


Salu2

Maximiliano Damian Accotto
Gerente de IT
Fundicion San Cayetano S.A.
Buenos Aires Argentina
-
maxi_accotto[arroba]speedy[.]com[.].ar
MSN:



"Jose Nadim" escribió en el mensaje
news:

Cordial saludo y prospero nuevo año para todos, estoy tratando de
manejar errores en un trigger remoto; en el caso de que el trigger(FOR
INSERT) inserte en el servidor remoto y èste està fuera de red..
maneje el error y el trigger inserte en una tabla local xa evitar que
se deshaga la instruccion..
espero haberme explicado bien . sin embargo envio el
trigger... agradezco sugerencias...


CREATE TRIGGER Llenar ON authors
FOR INSERT
AS
SET XACT_ABORT ON
insert into [SERVIDOR2].PUBS.dbo.autremoto (au_id , au_lname,
au_fname,phone, address , city,state,zip,contract )
SELECT au_id , au_lname, au_fname,phone, address ,
city,state,zip,contract from inserted
IF (@@ERROR <>0)
begin
GOTO ERRORES
ERRORES:
insert into pubs.dbo.autlocal (au_id , au_lname, au_fname,phone,
address , city,state,zip,contract )
SELECT au_id , au_lname, au_fname,phone, address ,
city,state,zip,contract from inserted
end

Jose Nadim

Aqui estas ante un gran dilema:

Si no ejecutas SET XACT_ABORT ON entonces el trigger no anda porque SQL
Server te mostrara el error de que no se pueden ejecutar transacciones
anidadas en un contexto distribuido. Pero si lo ejecutas ante cualquier
error deshace la transaccion automaticamente de todo, inclusive de la
instruccion que disparo el trigger.

En este caso creo que deberias buscar otro mecanismo para actualizar el
servidor remoto.

Saludos
Adrian D. Garcia
NDSoft






"Jose Nadim" wrote in message
news:

Cordial saludo y prospero nuevo año para todos, estoy tratando de
manejar errores en un trigger remoto; en el caso de que el trigger(FOR
INSERT) inserte en el servidor remoto y èste està fuera de red..
maneje el error y el trigger inserte en una tabla local xa evitar que
se deshaga la instruccion..
espero haberme explicado bien . sin embargo envio el
trigger... agradezco sugerencias...


CREATE TRIGGER Llenar ON authors
FOR INSERT
AS
SET XACT_ABORT ON
insert into [SERVIDOR2].PUBS.dbo.autremoto (au_id , au_lname,
au_fname,phone, address , city,state,zip,contract )
SELECT au_id , au_lname, au_fname,phone, address ,
city,state,zip,contract from inserted
IF (@@ERROR <>0)
begin
GOTO ERRORES
ERRORES:
insert into pubs.dbo.autlocal (au_id , au_lname, au_fname,phone,
address , city,state,zip,contract )
SELECT au_id , au_lname, au_fname,phone, address ,
city,state,zip,contract from inserted
end

Jose Nadim

OK, mil gracias a ambos por su interes,para Adrian :
tienes razon con la opcion en el trigger si no se setea con
Xact_Abort on la insercion no se realiza y por eso se me generacel
problema
Para Maximiliano : lo que quierpo es que aunque el servidor remoto
esté fuera de red no se bloqueen los procesos por culpa del
trigger.

Bueno ahora si el porqué de este trigger y su tratamiento de error:
Tengo algunas tablas que generan consecutivos y otros datos
adicionales, si en algun momento el servidor de produccion se cae debo
asegurarme de tener en otro servidor el ultimo numero dado en cada una
de esas tablas para seguir ofrciendo informacion con su respectivo
consecutivo real... ah bueno y si el servidor que debe recibir los
consecutivos no esta activo o en red el trigger deberia escribir en
una nueva tabla del local o no hacer nada para evitar que la
aplicacion se bloquee bueno es importante que decir este servicio
es 7x24,
por eso la idea del trigger..

Jose Nadim M.

Entonces Jose no te va aquedar mas remedio que utilizar una de las
siguientes opciones ya que la opción de los triggers no va a funcionar:

a) Usar alguna forma de replicacion, por ejemplo, transaccional: todas las
transacciones aplicadas al servidro A se aplican al servidor B. Si el
servidor A se cae el B pasaria a produccion, si se cae el link entre ellos o
el B esta fuera de servicio luego puede sincronizarse nuevamente

b) Log Shipping: esta es una tecnica parecida a la replicacion transaccional
pero sin la sobrecarga de la misma. Cada x tiempo se ejecuta un backup de
las transacciones del servidor A y se aplica al servidor B.

c) Armar un Cluster. Por lo lejos la opcion mas cara pero provee
disponibilidad real 7x24. Si se cae un servidor el otro empieza a atender
automaticamente los requerimientos del servidor caido. En las opciones A y B
esto generalmente requiere de un tratamiento manual. Pero si el sistema es
7x24 tal cual lo estas planteando quizas no te quede otra opcion.

Saludos
Adrian D. Garcia
NDSoft


"Jose Nadim" wrote in message
news:

OK, mil gracias a ambos por su interes,para Adrian :
tienes razon con la opcion en el trigger si no se setea con
Xact_Abort on la insercion no se realiza y por eso se me generacel
problema
Para Maximiliano : lo que quierpo es que aunque el servidor remoto
esté fuera de red no se bloqueen los procesos por culpa del
trigger.

Bueno ahora si el porqué de este trigger y su tratamiento de error:
Tengo algunas tablas que generan consecutivos y otros datos
adicionales, si en algun momento el servidor de produccion se cae debo
asegurarme de tener en otro servidor el ultimo numero dado en cada una
de esas tablas para seguir ofrciendo informacion con su respectivo
consecutivo real... ah bueno y si el servidor que debe recibir los
consecutivos no esta activo o en red el trigger deberia escribir en
una nueva tabla del local o no hacer nada para evitar que la
aplicacion se bloquee bueno es importante que decir este servicio
es 7x24,
por eso la idea del trigger..

Jose Nadim M.

OK. Adrian gracias por tu interes te explicare cual es el
modelo
con 15 tablas de la BD se puede ofrecer informacion a los usuarios
mientras se restaura el server de produccion(en caso de fallo
;-),todas las noches y al mediodia con un DTS pongo esas 15 tablas en
otro servidor, con esto garantizo de tener informacion de almenos 6
horas atrasado; de todas estas ,solo una la de los consecutivos
necesito asegurar tener siempre el ultimo numero dado para modificar
la tabla en la Bd de reserva y sigan dando informacion y registrando
las llamadas sin problemas de numeracion, luego cuando se restaure el
sistema
pasaria el nuevo consecutivo a produccion

a) Usar alguna forma de replicacion, por ejemplo, transaccional: todas las
transacciones aplicadas al servidro A se aplican al servidor B. Si el
servidor A se cae el B pasaria a produccion, si se cae el link entre ellos o
el B esta fuera de servicio luego puede sincronizarse nuevamente

Esto no me degrada demasiado el rendimento asi sea solo una tabla??? y
lo haria
al instante???

b) Log Shipping: esta es una tecnica parecida a la replicacion transaccional
pero sin la sobrecarga de la misma. Cada x tiempo se ejecuta un backup de
las transacciones del servidor A y se aplica al servidor B.

El log shipping funciona con version estandar de la 7.0? y si fuese
2000 cual version lo admite?

c) Armar un Cluster. Por lo lejos la opcion mas cara pero provee
disponibilidad real 7x24. Si se cae un servidor el otro empieza a atender
automaticamente los requerimientos del servidor caido. En las opciones A y B
esto generalmente requiere de un tratamiento manual. Pero si el sistema es
7x24 tal cual lo estas planteando quizas no te quede otra opcion.

En este si estoy totalmente de acuerdo pero ese sueño lo veo
lejano.

De nuevo agradezco sus sugerencias..

Jose Nadim M.