Hasta que punto puedo confiar en beginTrans y commitTrans?

[mariano_donati]

Hola, actualmente estoy trabajando con beginTrans y commitTrans para garantizar la integridad de las tablas de mi base de datos al momento de hacer actualizaciones que guardan alguna relación entre sí.
El esquema que sigo es más o menos similar a este:

Código:

ON ERROR RESUME NEXT
 
set conn = server.createObject("ADODB.connection")
	 conn.open strConn
	 conn.beginTrans
			conn.execute("insercion_de_registros")
			conn.execute("primera_actualizacion")
			conn.execute("segunda_actualizacion")
			if conn.errors.count = 0 then
			   conn.commitTrans
			else
			   'Muestro el mensaje de que se produjo un error al intentar			realizar	  la operación
			end if
	 conn.close()
set conn = nothing

Probandolo en local funciona correctamente, si detecta algún error en alguna de las tres ejecuciones que intenta hacer la conexion, me muestra el mensaje y no se realiza ninguna tarea.
Mis preguntas son dos:
1.-¿Se puede confiar en este método? o ¿tienen conocimiento de alguna falla que se le encuentra comunmente cuando se trabaja de esta forma?
2.-¿Cuales son los errores que detecta la coleccion errors del objeto conexion? ¿son solo errores de sintaxis u otros errores atribuibles al programador? o ¿también son errores como una caida en la conexion por x motivo, o una saturacion en las llamadas a la base de datos, etc?

Muchas gracias por su ayuda.
Saludos!.

[un_tio]

Qué casualidad que haya visto este tópic, porque he mandado hace un rato un mensaje a bases de datos, http://www.forosdelweb.com/f21/varios-accesos-vez-base-datos-sql-server-2000-a-316956/, preguntando lo mismo.

Yo he probado a no ejecutar el COMMIT TRANSACTION, y la tabla que había sido alterada se veía "en blanco" e imposible de modificar. ¿Esta es una de sus limitaciones, que si a mitad de proceso falla lo que sea, nos quedamos sin las tablas implicadas (hasta que alguien después vuelva a hacer un "COMMIT TRANSACTION")?

[mariano_donati]

Que buen post un_tio!, cuando decís se veía en blanco, también te referís a que la tabla queda sin poderse usar para leer registros? o solo para tareas de modificación, inserción y eliminación?. Con respecto a algo que mencionaste en el post, no estoy de acuerdo en que lo más grave que pueda llegar a pasar sin usar BEGIN TRANSACTION es que una tabla quede modificada y otra no, es decir, eso es gravísimo para mi gusto, y deberías hacerlo de esa manera, ya que como te comentaron en ese mismo post, hay formas de evitar ese posible error que comentas cuando no se ejecuta el COMMIT TRANSACTION. Si bien siempre uno va a realizar seguimientos a su base de datos para ver como anda todo, esos errores supongo yo que pueden ser fatales para la estructura general de la base de datos y deberían ser muy tenidos en cuenta por todos. Además, como lo corregirías? te irías fijando uno por uno los registros de cada una de las tablas que están relacionadas para ver si se corresponden entre sí? o lo harías de otra forma?
Un saludo un_tio, muy buen post como dije al principio.
Suerte!.

[Neuron_376]

Trans es lo mas seguro actualmente para esta clase de seguridad, de heho hasta los triggers estan basados en este concepto, lo que podria estar mal es la estructura que sigues...

la estructura debe ser como:

BEGIN TRANS

- execute SQL

if error then

ROLLBACK TRANS

end if

COMMIT

Esa seria la estructura, claro si nosotros no podemos bien el codigo, claro que cualquier procedimiento se vuelve inseguro.

Si ocurre un error y no pones el ROLLBACK siempre llega al COMMIT, pero claro con errores en la transaccion, las tablas son DESBLOQUEADAS pero con la posibilidad de malos datos.

Siempre lo he usado dentro de SP para hacerlo aun mas seguro, en mi opinion no veo el caso de usar trans desde ASP si sabes que dentro del servidor WEB puede haber un error independiente y entonces el TRANS no va a cumplir correctamente su cometido.

Recomiendo que eso sea completamente en el servidor de Bases de Datos, sino me parece que a algo seguro le estas agregando posibilidades de error.

Bueno, eso pienso.

Suerte!!

[mariano_donati]

Toda la razón te doy Neuron. Con la estructura que estaba utilizando solamente se cerraba la transacción si no había errores, si no era así, esta no se cerraba, lo cual estoy seguro que es algo malo para hacer, pero no se cuales son las consecuencias de dejar un transacción abierta (si es que no se cierra automáticamente al irse de la página el usuario).
Y con respecto a lo de SP, también es cierto, te aseguras de una parte del asunto, pero no del todo de esa forma. Ahora, como se hace dentro de un SP? Tenés algún ejemplo?. Estoy empezando con esto de SQL Server y los procedimientos almacenados, y según leí, hay que tener cuidado con cuantos procedimientos se crea, por que en lugar de favorecer quizás terminen ocupando espacio al vicio y perjudiquen la aplicación.
Nos vemos!.
Suerte!.

[Myakire]

Solo toma en cuenta que las transacciones hay que llevarlas en el servidor web y/o en el servidor de base de datos, ya que si quieres ir de uno al otro con sola una transacción, no funciona.

Se que es lógico pero no esta de más apuntarlo.

Si tengo una transacción en ASP con conn.beginTrans y dentro de ella llamó a un SP sin BEGIN TRANS, y en él algo falla, el ASP ni se enterá.

Saludos

[Neuron_376]

Un ejemplo basico es asi:

Código HTML:

CREATE PROCEDURE spNombre
	@spPrm varchar(255)
as
  begin

	BEGIN TRAN

		update tabla1 set Campo = @spPrm

		if @@ERROR <> 0 
		begin
			rollback tran
			return @@ERROR
		end
	
	COMMIT TRAN
	return 0
  end
GO

Suerte!!

[titon]

Tengo una pregunta con estos metodos:

Con un addnew y luego un update eso se consideraria dentro de las transacciones tambien o tienen q ser del tipo sql (insert, delete, update)?

[Myakire]

Como comenté en su momento, la transacción la puedes llevar en el ASP mediante el objeto connection (conn.beginTrans) o en la BD's con el BEGIN TRAN


Saludos