Trigger Remoto y GOTO

06/01/2004 - 00:03 por josenadim | Informe spam

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

Siga el debate

7 respuestas

Tengo una respuesta

Preguntas similare

Leer las respuestas

#6 Adrian Garcia

08/01/2004 - 00:09 | Informe spam

Basicamente lo que haria es lo mismo que intentaste hacer con el trigger.
Por lo cual no creo que habria mucha diferencia de rendimiento.
Que cantidad de movimientos por minuto (o por segundo) tienen la tablas?

Saludos
Adrian D. Garcia
NDSoft

"Jose Nadim" wrote in message
news:

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

> 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

> 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.

Responder a este mensaje

#7 josenadim

08/01/2004 - 15:32 | Informe spam

la frecuencia de de trabajo en las dos tablas es baja son solo dos
operadoras por lo tanto eso no es lo preocupante, lo malo es cuando el
trigger inserta en el equipo remoto si el remoto està fuera de red el
trigger deshace todo; ahora nose si la replicacion transaccional sea
excelente para este caso porque la bd en general tiene trabajo
fuerte.
gracias
Jose Nadim...

Siga el debate Respuesta

Responder a este mensaje

Ads by Google

Hacer una pregunta

Tengo una respuesta

1 2

Busqueda sugerida