Varios accesos a la vez a una base de datos de SQL Server 2000

[un_tio]

Puede pasar que varios usuarios intenten acceder a la vez a una misma base de datos.

Mi duda es: ¿de eso ya se encarga solo el SQL Server 2000 (si varios usuarios, a través de una página web, intentan leer o insertar datos a la vez en la base de datos), o hay que programar algo para evitar algunos tipo de errores?

[Mithrandir]

SQL Server se encarga de la concurrencia (meter a varios usuarios a la vez al mismo recurso), pero tu te tienes que hacer responsable de a "atomicidad" de tus procedimientos, esto es, si tienes 2 operaciones que solo se deban ejecutar juntas pero no separadas, entonces lo tienes que controlar tu.

Para eso utilizas las transacciones, algo como
BEGIN TRANSACTION
INSERT algo
UPDATE otracosa
...
¿todo bien?
si-> COMMIT TRANSACTION
no-> ROLLBACK TRANSACTION

Con esto te libras de los "errores" de la concurrencia al insertar/modificar datos.

[un_tio]

¿Cuándo queremos "atomicidad"? No me ha quedado muy claro en qué casos debería hacer eso de "Begin Transaction" (por cierto, que supongo que deberá acabar con End Transaction, ¿no?).

[xaquin]

ejemplo: traspaso de dinero de una cuenta a otra

saco 50 € de la cuenta a y los quiero meter en la cuenta b. La transacción consta de dos partes, por un lado un "delete" (en realidad será un update pero bueno) de la cuenta a y un "insert" (otra vez un update) en la cuenta b

Ahora imagínate que se va la luz en medio de la operación, en qué estado queda esa operación?Tienes que asegurar que se realizan las dos operaciones y no sólo una a eso se refiere Mithrandir con lo de "atomicidad"

Espero que te quede claro

[Mithrandir]

Atomicidad es una de las partes, el conjunto completo se el suele llamar ACID.

No, END TRANSACTION no existe en TSQL, para terminar una transaccion usas COMMIT TRANSACTION (aplicar los cambios) o ROLLBACK TRANSACTION (deshacer TODA la transaccion) según sea el caso.

El cuando la usas depende de tu criterio y de las necesidades de la aplicación, en general las usas cuando modificas más de 2 lugares a la ves.

[un_tio]

Muy interesante.

Lo de BEGIN TRANSACTION podría serme útil, ya que precisamente hay una operación en la que hago dos cosas en la base de datos, pero si una de las dos sale mal no quiero que la otra se ejecute.

Ahora mismo, lo que hago es ejecutar una instrucción, comprobar: si está bien, hago la siguiente, si no, no. Compruebo la segunda instrucción, si está bien, todo perfecto, si está mal, deshago la primera instrucción.

He probado a usar el TRANSACTION y me funciona de maravilla, pero podría haber un eventual problemilla:

Yo voy ejecutando instrucciones SQL (no sé si esto estará bien, o debería meterlas todas en una), y hago:

SQL="BEGIN TRANSACTION"
oConn.Execute (SQL)
SQL="mi_instruccion" (es un ejemplo)
oConn.Execute (SQL)
...

Entonces, mi duda es: ¿qué pasaría si justo la última instrucción que debe hacerse (ROLLBACK o COMMIT) no se hace? (que podría ocurrir si, por ejemplo, se va la luz en ese momento) Pues, que tal y como he comprobado (no apagando el ordenador, sino simplemente comenzando una transacción y no finalizándola (lo cual no sé si será equivalente, y si no lo es espero que alguien me lo diga)), la tabla sobre la que se hizo una instrucción queda inutilizada, a la espera de que el sistema reciba una de las dos órdenes (ROLLBACK o COMMIT).

¿Resulta esto seguro? Es decir: si no uso "BEGIN TRANSACTION", con mis "apaños" lo más grave que puede llegar a ocurrir, si algo fallara, es que se quedara una tabla modificada que no se corresponde bien con otra; y esto es fácil de arreglar por una persona que vaya, mire las tablas y borre lo que quiera.

Ahora bien, con COMMIT ya no es lo mismo... se queda "en el aire" y el problema, aunque de fácil solución (ir y ejecutar un "COMMIT"), puede ser más difícilmente detectable.

¿Soluciones ante una eventual pérdida o no ejecución de la instrucción de finalización de la transacción?

[Mithrandir]

Para evitar el "se apagó a medio commit" se utiliza una tecnica llamada (si no mal recuerdo) Write Ahead, donde antes de dar por finalizado el commit se asegura de haber escrito todo bien.

Si se apagó a "medio commit" al reiniciar el servicio pasa la "barredora" y deshará la transacción que "casi" terminaba.