Sugerencias para Query

Hola...
Podrías probar manejando despues de cada transacción
revisar si @@error es diferente de cero y guardas el texto
q definiste o vas a buscar la descripción del error y esa
guardas ... ojala te sirva

Saludos

Hola grupo,

Tengo un SP que realiza varios procesos internamente. En

su totalidad son

ingresos de datos con algunnas excepciones donde se

realizan

actualizaciones. En total son unas 15 tablas

aproximandamente.

Lo que necesito es controlar la inserción/actualización

de datos para cada

una de estas; en caso de haber error, guardar este en una

tabla de Logs ya

definida . He estado investigando la utilización de Begin

Transaction con

sus respectivos Commit o Rollback, pero me gustaría tener

alguna

recomendación por parte de ustedes en la construcción del

Query.

La lógica del código T-SQL sería algo así:

SP_CargaDeDatos
Begin

Insert TablaDestino1 Campo1,Campo2,Campo3
Select Campo1
Campo2
Campo3
From TablaOrigen1

('Problemas al

Insertar en el Proceso 1.', 16, 1)


Insert TablaDestino2 Campo1,Campo2,Campo3
Select Campo1
Campo2
Campo3
From TablaOrigen2

('Problemas al

Actualizar en el Proceso 2.', 16, 1)

Insert TablaDestino3 Campo1,Campo2,Campo3
Select Campo1
Campo2
Campo3
From TablaOrigen3

('Problemas al

Insertar en el Proceso 3.', 16, 1)
.
.
.
etc.

End

¿Cuál es la mejor forma de controlar las transacciones?

¿Donde las utlizo

para guardar el error en la tabla de Logs?

Gracias.

RCA.


.

Ok, así lo tenía pensado, pero ¿Como manejo el tema del Rollback en caso de
que hubo un problema ya sea de inserción o de actualización?, entiendo que
esto debería ser por cada tabla cierto???...


"Pedro" escribió en el mensaje
news:269e101c462b9$db93b9e0$
Hola...
Podrías probar manejando despues de cada transacción
revisar si @@error es diferente de cero y guardas el texto
q definiste o vas a buscar la descripción del error y esa
guardas ... ojala te sirva

Saludos

Hola grupo,

Tengo un SP que realiza varios procesos internamente. En

su totalidad son

ingresos de datos con algunnas excepciones donde se

realizan

actualizaciones. En total son unas 15 tablas

aproximandamente.

Lo que necesito es controlar la inserción/actualización

de datos para cada

una de estas; en caso de haber error, guardar este en una

tabla de Logs ya

definida . He estado investigando la utilización de Begin

Transaction con

sus respectivos Commit o Rollback, pero me gustaría tener

alguna

recomendación por parte de ustedes en la construcción del

Query.

La lógica del código T-SQL sería algo así:

SP_CargaDeDatos
Begin

Insert TablaDestino1 Campo1,Campo2,Campo3
Select Campo1
Campo2
Campo3
From TablaOrigen1

('Problemas al

Insertar en el Proceso 1.', 16, 1)


Insert TablaDestino2 Campo1,Campo2,Campo3
Select Campo1
Campo2
Campo3
From TablaOrigen2

('Problemas al

Actualizar en el Proceso 2.', 16, 1)

Insert TablaDestino3 Campo1,Campo2,Campo3
Select Campo1
Campo2
Campo3
From TablaOrigen3

('Problemas al

Insertar en el Proceso 3.', 16, 1)
.
.
.
etc.

End

¿Cuál es la mejor forma de controlar las transacciones?

¿Donde las utlizo

para guardar el error en la tabla de Logs?

Gracias.

RCA.


.

Hola:
Hay otras alternativas, a mi me gusta:
=IF EXISTS(...)
BEGIN
RAISERROR(...)
RETURN 1
END
IF EXISTS(..)
BEGIN
RAISERROR(...)
RETURN
END

BEGIN TRAN

INSERT ...
IF @@ERROR <> THEN
BEGIN
RAISERROR(...)
ROLLBACK
RETURN 1
END

INSERT ...
IF @@ERROR <> THEN
BEGIN
RAISERROR(...)
ROLLBACK
RETURN 1
END
COMMIT
= Algunos comentarios, analiza primer condiciones de los datos sin iniciar
la transaccion, en caso de problemas evitas del todo iniciar la transaccion.
Inicia la transaccion tan tarde como sea posible y la cierras lo mas rapido.
Siempre usas una combinacion Rollback, RaiseError, Return.
Saludos,


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.


RCA escribio:

Hola grupo,

Tengo un SP que realiza varios procesos internamente. En su totalidad
son ingresos de datos con algunnas excepciones donde se realizan
actualizaciones. En total son unas 15 tablas aproximandamente.

Lo que necesito es controlar la inserción/actualización de datos para
cada una de estas; en caso de haber error, guardar este en una tabla
de Logs ya definida . He estado investigando la utilización de Begin
Transaction con sus respectivos Commit o Rollback, pero me gustaría
tener alguna recomendación por parte de ustedes en la construcción
del Query.

La lógica del código T-SQL sería algo así:

SP_CargaDeDatos
Begin

Insert TablaDestino1 Campo1,Campo2,Campo3
Select Campo1
Campo2
Campo3
From TablaOrigen1
Insertar en el Proceso 1.', 16, 1)


Insert TablaDestino2 Campo1,Campo2,Campo3
Select Campo1
Campo2
Campo3
From TablaOrigen2
Actualizar en el Proceso 2.', 16, 1)

Insert TablaDestino3 Campo1,Campo2,Campo3
Select Campo1
Campo2
Campo3
From TablaOrigen3
Insertar en el Proceso 3.', 16, 1)
.
.
.
etc.

End

¿Cuál es la mejor forma de controlar las transacciones? ¿Donde las
utlizo para guardar el error en la tabla de Logs?

Gracias.

RCA.

Ok, entiendo tu sugerencia, pero manejo un volumen de datos para algunas
tablas que supera los 13.000 registros por día.

Al realizar los que me dices, la revisión previa, ¿No consumiría recursos
demás del Server?, me parece una buena idea, pero creo que esto sería un
problema.

Por otro lado, ¿manejo una sola transacción que englobe a todos los
insert/update? o una transacción por tabla???

Gracias.

"Javier Loria" escribió en el mensaje
news:

Hola:
Hay otras alternativas, a mi me gusta:
=> IF EXISTS(...)
BEGIN
RAISERROR(...)
RETURN 1
END
IF EXISTS(..)
BEGIN
RAISERROR(...)
RETURN
END

BEGIN TRAN

INSERT ...
IF @@ERROR <> THEN
BEGIN
RAISERROR(...)
ROLLBACK
RETURN 1
END

INSERT ...
IF @@ERROR <> THEN
BEGIN
RAISERROR(...)
ROLLBACK
RETURN 1
END
COMMIT
=> Algunos comentarios, analiza primer condiciones de los datos sin

iniciar

la transaccion, en caso de problemas evitas del todo iniciar la

transaccion.

Inicia la transaccion tan tarde como sea posible y la cierras lo mas

rapido.

Siempre usas una combinacion Rollback, RaiseError, Return.
Saludos,


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.


RCA escribio:
> Hola grupo,
>
> Tengo un SP que realiza varios procesos internamente. En su totalidad
> son ingresos de datos con algunnas excepciones donde se realizan
> actualizaciones. En total son unas 15 tablas aproximandamente.
>
> Lo que necesito es controlar la inserción/actualización de datos para
> cada una de estas; en caso de haber error, guardar este en una tabla
> de Logs ya definida . He estado investigando la utilización de Begin
> Transaction con sus respectivos Commit o Rollback, pero me gustaría
> tener alguna recomendación por parte de ustedes en la construcción
> del Query.
>
> La lógica del código T-SQL sería algo así:
>
> SP_CargaDeDatos
> Begin
>
> Insert TablaDestino1 Campo1,Campo2,Campo3
> Select Campo1
> Campo2
> Campo3
> From TablaOrigen1
> Insertar en el Proceso 1.', 16, 1)
>
>
> Insert TablaDestino2 Campo1,Campo2,Campo3
> Select Campo1
> Campo2
> Campo3
> From TablaOrigen2
> Actualizar en el Proceso 2.', 16, 1)
>
> Insert TablaDestino3 Campo1,Campo2,Campo3
> Select Campo1
> Campo2
> Campo3
> From TablaOrigen3
> Insertar en el Proceso 3.', 16, 1)
> .
> .
> .
> etc.
>
> End
>
> ¿Cuál es la mejor forma de controlar las transacciones? ¿Donde las
> utlizo para guardar el error en la tabla de Logs?
>
> Gracias.
>
> RCA.

Hola:
La idea de hacer la revision previa es evitar el consumo innecesario de
recursos. El codigo que te posteo es mas rapido, bastante mas rapido (a
pesar que no lo parezca). La razon es que evita las transacciones
innecesarias.
Por ejemplo si en una entrada que afecta la tabla numero 15 de consulta
se rompe algun CONSTRAINT(CHECK o FK), el servidor para entonces ya grabo en
el Transaction Log (que no tiene cache), y tiene que hacer ROLLBACK de las
14 modificaciones previas. Otra razon por la que es muy rapido es que inicia
la transaccion lo mas tarde posible reduciendo al minimo los bloqueos.
La desventaja de este codigo es que a pesar de haber validado
previamente los datos siempre es necesario volver a revisar si se produjo
error ya que al no haber bloqueos podrian cambiar los datos. Y que es largo
y feo de escribir ya que tienes que validar doblemente.
Definitivamente en la mayoria de los casos una transaccion, a menos que
no te importe que queden las modificaciones en 10 tablas y las ultimas 5 no.
(Ejemplo caida de Red, Servidor, Aplicacion, etc.)
Saludos,


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.

RCA escribio:

Ok, entiendo tu sugerencia, pero manejo un volumen de datos para
algunas tablas que supera los 13.000 registros por día.

Al realizar los que me dices, la revisión previa, ¿No consumiría
recursos demás del Server?, me parece una buena idea, pero creo que
esto sería un problema.

Por otro lado, ¿manejo una sola transacción que englobe a todos los
insert/update? o una transacción por tabla???

Gracias.

"Javier Loria" escribió en el mensaje
news:

Hola:
Hay otras alternativas, a mi me gusta:
=>> IF EXISTS(...)
BEGIN
RAISERROR(...)
RETURN 1
END
IF EXISTS(..)
BEGIN
RAISERROR(...)
RETURN
END

BEGIN TRAN

INSERT ...
IF @@ERROR <> THEN
BEGIN
RAISERROR(...)
ROLLBACK
RETURN 1
END

INSERT ...
IF @@ERROR <> THEN
BEGIN
RAISERROR(...)
ROLLBACK
RETURN 1
END
COMMIT
=>> Algunos comentarios, analiza primer condiciones de los datos sin
iniciar la transaccion, en caso de problemas evitas del todo iniciar
la transaccion. Inicia la transaccion tan tarde como sea posible y
la cierras lo mas rapido. Siempre usas una combinacion Rollback,
RaiseError, Return. Saludos,


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.


RCA escribio:

Hola grupo,

Tengo un SP que realiza varios procesos internamente. En su
totalidad son ingresos de datos con algunnas excepciones donde se
realizan actualizaciones. En total son unas 15 tablas
aproximandamente.

Lo que necesito es controlar la inserción/actualización de datos
para cada una de estas; en caso de haber error, guardar este en una
tabla de Logs ya definida . He estado investigando la utilización
de Begin Transaction con sus respectivos Commit o Rollback, pero me
gustaría tener alguna recomendación por parte de ustedes en la
construcción del Query.

La lógica del código T-SQL sería algo así:

SP_CargaDeDatos
Begin

Insert TablaDestino1 Campo1,Campo2,Campo3
Select Campo1
Campo2
Campo3
From TablaOrigen1
al Insertar en el Proceso 1.', 16, 1)


Insert TablaDestino2 Campo1,Campo2,Campo3
Select Campo1
Campo2
Campo3
From TablaOrigen2
al Actualizar en el Proceso 2.', 16, 1)

Insert TablaDestino3 Campo1,Campo2,Campo3
Select Campo1
Campo2
Campo3
From TablaOrigen3
al Insertar en el Proceso 3.', 16, 1)
.
.
.
etc.

End

¿Cuál es la mejor forma de controlar las transacciones? ¿Donde las
utlizo para guardar el error en la tabla de Logs?

Gracias.

RCA.