TRANSACCIONES ANIDADAS
Fernando
NECESITO HACER UNA SERIE DE PROCEDIMIENTOS, EN SQL 2005 STD.
NECESITO HACER UNOS INSERTS, UPDATE Y DELETE EN UN MISMO SP, Y QUIERO
IMPLEMENTAR TRANSACCIONES, O SEA IR HACIENDO LAS TRANSACCIONES PERO
DENTRO DE UNA GENERAL,. NO SE SI ME EXPLICO
EL TEMA ES QUE SI ALGUNA TRANSACCION INTERNA ME FALLA, QUE EL
PROCEDIMIENTO VUELVA PARA ATRAZ TODO, HAGA EL ROLLBACK Y ADEMAS ME
DIGA EN QUE SUBTRANSACCION SE PRODUJO LA FALLA. POR EJMPLO SI TENGO
QUE HACER UN INSERT, UN DELETE, Y UN UPDATE. Y LA TRANSACCION FALLA EN
EL DELETE. QUE EL SP ME DIGA QUE EL ERROR SE PRODUJO EN EL DELETE Y
QUE HAGA EL ROLLBACK DE LA TRANSACCION GENERLA
ESTUVE LEYENDO EN LOS BOOKS,ENCONTRE ALGO SOBRE ANIDADAS Y MARCAS DE
TRANSACCIONES, PERO NO VEO COMO IMPLEMENTAR ESO PARA QEU FUNCIONE EN
MI ESCENARIO.
GRACIAS! ESPERO SU RESPUESTA
Penta
Solo por curiosidad, porque necesitas transacciones anidadas ?? eso es
valido ??
Ejemplo:
Primer Begin tran
Transacciones
Segundo begin tran
Transacciones
Primer commit o rollback
Segundo commit o Rollback
Para que el Primer commit o Rollback ??? en que caso SI te serviria ??
Atte.
Penta.
Alfredo Novoa
Hola Penta,
On Mon, 19 May 2008 16:25:16 -0700 (PDT), Penta
<crist...@gmail.com> wrote:
>Hola Fernando.
>Solo por curiosidad, porque necesitas transacciones anidadas ?? eso es
>valido ??
Claro que es válido, y SQL Server lo permite.
>
>Ejemplo:
>
>Primer Begin tran
> Transacciones
> Segundo begin tran
> Transacciones
> Primer commit o rollback
>Segundo commit o Rollback
>
>Para que el Primer commit o Rollback ??? en que caso SI te serviria ??
Pues sirve para descomponer transacciones largas en unidades más
pequeñas que pueden ser confirmadas o aunuladas independientemente.
Por ejemplo si tienes una transacción muy muy larga y te encuentras un
error por el final, si no usas transacciones anidadas al hacer un
rollback pierdes todos los cambios y tienes que comenzar de nuevo. En
cambio si usas transacciones anidadas si encuentras un error solo
tienes que anular y repetir un subgrupo de las operaciones.
Cualquier SGBD serio debe de permitir las transacciones anidadas.
Saludos
Alfredo
Penta
Me refería a esto:
"EL TEMA ES QUE SI ALGUNA TRANSACCION INTERNA ME FALLA, QUE EL
PROCEDIMIENTO VUELVA PARA ATRAZ TODO"
Si queremos volver atras todo para que necesito transacciones
anidadas ?
Atte.
Penta.
Alfredo Novoa
Hola Penta,
Hombre, me imagino que quiere volver para atrás la "subtransaccion".
Saludos
Alfredo
Penta
No se o tengo sueño o estoy leyendo muy mal leo claramente que dice:
"QUE HAGA EL ROLLBACK DE LA TRANSACCION GENERLA "
O sea que haga rollback a TODO :)
Atte.
Penta.
Alfredo Novoa
Bueno, yo es que paso de leer los mensajes que están con todas las
letras en mayúsculas, pero en ese caso no tendría ningún sentido.
Saludos
Alfredo
Penta
Un saludo.
Penta.
flprincich
la idea era saber en que subtransaccion se generó el error, por
ejmplo... tengo 3 inserts y en el medio un delete, y me falla el
delete. saber que la que fallo fue la subtransacción que debia elimar
registro, pero al mismo tiempo por supuesto hacer rollback de todo, no
se solamente los inserts. capaz me expresé mal
Disculpen y saludos!
p/d: que pasa si en el medio quiero conectarme a un servidor remoto y
hacer lo mismo, misma transaccion, en el servidor remoto, no puedo
implementar clusters porq mi conectivad no es eficiente. o sea solo
deseo replicar ésta transacción, las demas no son necesarias.
Gracias otra vez, y perdon por las mayúsculas...
Miguel Egea
Primero lo primero en OT ( Escribir en mayúsculas en el mundo internet se
considera gritar, como supongo que tu intención no es gritarnos a todos pues
prefiero decirtelo a que alguien se te ofenda)
Después:
Simplemente con poner begin tran y sus correspondientes commits tendrías
suficiente para anidar transacciones. la variable @@trancount te devuelve en
que "nivel de anidamiento" estás. De todas formas ojo, por que un commit
solo valida una transacción y un rollback las invalida todas @@trancount
pasaa valer 0.
Si usas SQL 2005, lo suyo es que uses los try catch y que devuelvas errores
a las capas superiores.
Sobre lo que has leido seguramente será sobre los savepoints, los savepoints
te valndrán como un begin tran si al final haces commit, solo son algo más
útiles si haces rollback pero ese trocito de codigo no es "critico", es
decir, dentro de un savepoint puedes hacer rollback del savepoint sin que
@@trancount vuelva a valer 0.
Espero que con todo este galimatias hayamos aclarado algo. (y espero no
estar muy oxidado en el motor relacional)
Un abrazo
Miguel Egea
"Fernando" <flpri...@gmail.com> wrote in message
news:5a71207b-47c1-4b62...@l42g2000hsc.googlegroups.com...
Alfredo Novoa
El Tue, 20 May 2008 15:00:29 -0700 (PDT), flprincich escribió:
> On 20 mayo, 14:48, Penta <cristian...@gmail.com> wrote:
> la idea era saber en que subtransaccion se generó el error, por
> ejmplo... tengo 3 inserts y en el medio un delete, y me falla el
> delete. saber que la que fallo fue la subtransacción que debia elimar
> registro, pero al mismo tiempo por supuesto hacer rollback de todo, no
> se solamente los inserts. capaz me expresé mal
No entiendo. Si ejecutas las instrucciones desde una aplicación puedes
saber fácilmente que instrucción ha fallado. Las transacciones anidadas no
son para eso. Son para poder confirmar y anular las subtransacciones
individualmente.
Saludos
Alfredo Novoa
Hola Miguel,
On Wed, 21 May 2008 00:15:41 +0200, "Miguel Egea"
<webm...@portalsql.com> wrote:
>Simplemente con poner begin tran y sus correspondientes commits tendrías
>suficiente para anidar transacciones. la variable @@trancount te devuelve en
>que "nivel de anidamiento" estás. De todas formas ojo, por que un commit
>solo valida una transacción y un rollback las invalida todas @@trancount
>pasaa valer 0.
Entonces para hacer lo que quiere le podría servir leer el valor de
@@trancount después de un error. Aunque sigo sin verle sentido a la
cosa.
Saludos
Alfredo
Carlos M. Calvelo
On 21 mei, 10:43, Alfredo Novoa <alfred...@gmail.com> wrote:
> Hola Miguel,
>
> On Wed, 21 May 2008 00:15:41 +0200, "Miguel Egea"
>
> <webmas...@portalsql.com> wrote:
> >Simplemente con poner begin tran y sus correspondientes commits tendrías
> >suficiente para anidar transacciones. la variable @@trancount te devuelve en
> >que "nivel de anidamiento" estás. De todas formas ojo, por que un commit
> >solo valida una transacción y un rollback las invalida todas @@trancount
> >pasaa valer 0.
>
> Entonces para hacer lo que quiere le podría servir leer el valor de
> @@trancount después de un error. Aunque sigo sin verle sentido a la
> cosa.
>
Claro que no tiene sentido.
Si lo que quiere es hacer siempre un rollback a la transacción
principal solo tiene que tener una variable que le dice donde
algo falló (hasta donde llegó). O como tienen que ser las
cosas, después de cada consulta hacer un poco de error
handling con @@error y ya está.
Las transacciones anidadas no son para eso.
Saludos,
Carlos
Carlos Sacristan
... CATCH (si está usando SQL 2005)
Miguel Egea
transacciones anidadas usadas para su fín están genial, pero como todo tiene
su dificultad que acabe funcionando bien de verdad, Tengo un correo de la
persona que originó el mensaje y básicamente me comenta que lo ha
solucionado con try-catch y consultando @@error, aún así creo que lo
interesante de los hilos no es solo resolver el problema puntual, sino lo
que aprendemos los que lo leemos y lo que enriquecen las opiniones (sobre
todo si son bien fundamentadas :))
A vuestra disposición
Miguel Egea
"Carlos M. Calvelo" <c_ja...@hotmail.com> wrote in message
news:ddb1af49-7efc-4a0c...@56g2000hsm.googlegroups.com...
Carlos M. Calvelo
On 21 mei, 13:30, "Miguel Egea" <webmas...@portalsql.com> wrote:
> Bueno, al final existen y la gente las usa como cree más conveniente.
Hombre... cómo no?
Yo las uso a veces para poner café. :-)
> Las
> transacciones anidadas usadas para su fín están genial,
Para su fin claro que están genial. Para mi, simplemente
error handling, no es su fín.
> pero como todo tiene
> su dificultad que acabe funcionando bien de verdad, Tengo un correo de la
> persona que originó el mensaje y básicamente me comenta que lo ha
> solucionado con try-catch y consultando @@error,
No me había dado cuenta que usaba SS2005.
La idea es la misma.
> aún así creo que lo
> interesante de los hilos no es solo resolver el problema puntual, sino lo
> que aprendemos los que lo leemos y lo que enriquecen las opiniones (sobre
> todo si son bien fundamentadas :))
>
Espero no haber dado la impresión que yo no
pienso también así.
Saludos,
Carlos
Carlos M. Calvelo
<CarlosSacris...@discussions.microsoft.com> wrote:
> Más que con @@ERROR, lo suyo sería, como comenta Miguel, con el bloque TRY
> ... CATCH (si está usando SQL 2005)
>
Totalmente de acuerdo. Como le digo a Miguel, lo he
puesto sin pensar que usa SS2005.
Saludos,
Carlos
Miguel Angel
Te recomiento que utilices transacciones con nombres, asi podras controlar
cual te falla. Para eso utiliza:
BEGIN TRAN <nombretransaccion>
Saludos,
Samuel
BEGIN TRANSACTION MANT_USUARIO
BEGIN TRY
*Aqui colocas todo tu procedimiento
*Puedes llamar tambien a otros procedimientos , cada SP. debera
tener nombre de transaccion diferente.
END TRY
BEGIN CATCH /* Hay un error, deshacemos los cambios*/
ROLLBACK TRANSACTION MANT_USUARIO
DECLARE @ErrorMessage NVARCHAR(4000);
DECLARE @ErrorSeverity INT;
DECLARE @ErrorState INT;
DECLARE @ErrorProcedure NVARCHAR(40);
DECLARE @ErrorLine INT; SELECT
@ErrorMessage = ERROR_MESSAGE(),
@ErrorSeverity = ERROR_SEVERITY(),
@ErrorState = ERROR_STATE(),
@ErrorProcedure = ERROR_PROCEDURE(),
@ErrorLine = ERROR_LINE();
RAISERROR (@ErrorMessage,
@ErrorSeverity,
@ErrorState,
@ErrorProcedure,
@ErrorLine )
END CATCH
SET NOCOUNT OFF
PD... Esto me funciona perfectamente, lo que quisiera es poder devolver los
errores en Castellano, si lo has desarrollado podrias postearlo?
"Miguel Angel" <Migue...@discussions.microsoft.com> escribió en el
mensaje de noticias:86608629-50FE-445A...@microsoft.com...