set autocommit=0

[josehi...@gmail.com]

=SQLExec(CcConexion,"set autocommit=0")

= SQLExec(CcConexion,"START TRANSACTION")

estas sentencias donde es mejor colocarlas en el form,

en el load? o cada vez que inicio un proceso de update o de insert?

aclarando que es el mismo form donde actualizo varias tablas o

inserto movimientos. encabezado de factura asi como detalle de la misma

gracias

[Daniel Sánchez]

Las transacciones deben darse solo al momento exacto en que se realiza la grabación correspondiente, apenas se termina de realizar la grabación finalizar la transacción, el tema de la transacción es conveniente para cuando se realiza la grabación de múltiples tablas a la vez, cuando la grabación de una de ellas falla se revierte las grabaciones realizadas, es decir todo se graba o nada (evitando de esta manera inconsistencia de datos) además se debe manejar integridad referencial entre tablas ejemplo clásico una tabla detalle al ingresar un registro debe tener en la tabla cabecera su registro correspondiente, o si se elimina su registro cabecera no permitir eliminar si existen referencias en la tabla detalle, o en todo caso realizar en cascada la eliminación de los registros relacionados con la tabla cabecera en la tabla detalle.

Saludos

--

Daniel Sánchez Escobar
Investigación y Desarrollo
Reset Software & Sistemas
Móvil +051-949398047 RPM #948615385
Trujillo - Perú

P  Sugerimos no imprimir este e-mail a menos que sea absolutamente necesario. Protejamos el medio ambiente.

[Carlos Miguel FARIAS]

Cuando inicias una transaccion, todos los elementos accedidos (registros) van quedando "capturados" por dicha transacción (aislados = isolation, la I de ACID), que sería el equivalente a un LOCK de Fox.

Esos elementos recien se liberan cuando haces un COMMIT o un ROLLBACK.

Tal como dice Daniel, el comienzo de la transacción debe ser en el momento que vas a empezar a modificar los registros y terminar en el momento de que se termina la modificación.

Es fundamental que en el medio del proceso de actualización/inserción de datos, no haya "peticiones" del usuario, o sea, el usuario tiene que quedar fuera del proceso, no permitir que introduzca "bocadillos", porque allí el fulano, se fue a comer, se rascó la cabeza, o pestañeo, y un simple pestañeo (0,1"?) son miles de ciclos de procesamiento, esperando ese simple pestañeo.

Una alternativa a dichos procesos largos es trabajar con un modelo de estados, usas un campo para indicar el estado del registro y otro para indicar un id de transacción.

Cuando una aplicación arranca genera un id (p.e. sys(0) + TOC(DATETIME())), eso identifica una corrida de un usuario, desde un pc iniciada en cierto momento.

Ese valor es público (para la aplicación), luego, cuando necesitas modificar "capturar" registros, cambias el estado (a algo que signifique "ocupado", "en proceso") y cargas el id de corrida.

Cuando terminas el proceso, colocas el estado en el que corresponda y borras el id de corrida.

De esa manera, si otro usuario quiere usar el registro, puede detectar que está en uso y, si es necesario, quien lo usa.

Si hay una falla "estrepitosa" del sistema (corte de luz, cuelgue del S.O., aplicación, lo que sea), un programa de arranque, puede detectar transacciónes incompletas, o hechas a media, y tomar medidas de restauración.

Eso es práctico (esta metodología) cuando se hacen procesos donde por las razones que sean, no se puede mantener una conexión permanente entre cliente y servidor (por ejemplo, en una aplicación en una extranet, o una web).

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe.