Manejo de transacciones en SQL server

[[poliburro]]

lo mejor es que coloques las transacciones en Sql server.

Pues almacenar la información de facturación en un Xml, enviarla al servidor convertirla a un recorset y guardar los datos en un bloque transaccional con su respectivo manejo de errores.

Colocar las transacciones en los clientes es una mala práctica.

[look]

Empezado por poliburro

lo mejor es que coloques las transacciones en Sql server.

Pues almacenar la información de facturación en un Xml, enviarla al servidor convertirla a un recorset y guardar los datos en un bloque transaccional con su respectivo manejo de errores.

Colocar las transacciones en los clientes es una mala práctica.

hola , gracias por responder ,¿podrias mostrarme un ejemplo?...

[ContraVeneno]

Pues por lo pronto yo veo un error bastante común (al menos lo he visto es muchos programas).

En tu código al ocurrir una excepción, muestras el mensaje de error y después haces el rollback.

Ahora imagina al clásico usuario al cuál le dan ñañaras las computadoas:

- "ok, hoy si voy a trabajar.. vamos a ver.. crear factura.. capturar... ¡CHANGOS!, esta mugre ya marcó un error...."
Se levanta de su silla, se va a preparar un café, platica con la secretaría, luego va con el guardia a platicar de futbol y después de todo eso va con el de sistemas a reportarle el error.

Durante todo ese tiempo, como nunca le dio aceptar al error, la transacción siguió activa, bloqueando a todos los demás usuarios.

Solución: Ejecuta el RollBack primero y después muestra el error.

Como sugerencia, trataría de hacer las excepciones más específicas y no utilizar el E:Exception, si no la clase del error que estoy esperando, EDBEngine por ejemplo. Y cambiaría el mensaje por: 'Ocurrió un error al intentar guardar. ' +#13+E.ClassName+' - '+E.Message Pero es cosa personal, eso de decir "posteo" no me gusta a mi para nada...

[look]

Empezado por ContraVeneno

Pues por lo pronto yo veo un error bastante común (al menos lo he visto es muchos programas).

En tu código al ocurrir una excepción, muestras el mensaje de error y después haces el rollback.

Ahora imagina al clásico usuario al cuál le dan ñañaras las computadoas:

- "ok, hoy si voy a trabajar.. vamos a ver.. crear factura.. capturar... ¡CHANGOS!, esta mugre ya marcó un error...."
Se levanta de su silla, se va a preparar un café, platica con la secretaría, luego va con el guardia a platicar de futbol y después de todo eso va con el de sistemas a reportarle el error.

Durante todo ese tiempo, como nunca le dio aceptar al error, la transacción siguió activa, bloqueando a todos los demás usuarios.

Solución: Ejecuta el RollBack primero y después muestra el error.

Como sugerencia, trataría de hacer las excepciones más específicas y no utilizar el E:Exception, si no la clase del error que estoy esperando, EDBEngine por ejemplo. Y cambiaría el mensaje por: 'Ocurrió un error al intentar guardar. ' +#13+E.ClassName+' - '+E.Message Pero es cosa personal, eso de decir "posteo" no me gusta a mi para nada...

Gracias por responder amigo ContraVeneno, efectivamente ,estoy deacuerdo con todo le me explicas aqui, esos puntos ya los habia resuelto segun lo que me dices ,lo de Rollback y todo lo demas , esque puse el codigo al vuelo , y lo de Posteo , pos igual no se me ocurrio otra palabra en el momento ... nuevamente gracias por responder

[[poliburro]]

Empezado por ContraVeneno

Durante todo ese tiempo, como nunca le dio aceptar al error, la transacción siguió activa, bloqueando a todos los demás usuarios.

Excelente ejemplo amigo contra, Esa es la gran razón por la que es una malisima práctica colocar las transacciones en los clientes.

a eso agregale que el programa se bloquea antes de lanzar el rollback.

las transacciones deben ser controladas por el manejador de bd