Forma recomendada de usar las transacciones con Firebird

[BD Learner]

Me dicen que las transacciones (en general) se pueden hacer desde el lenguaje (como Visual Foxpro, por ejemplo), pero que tambien se pueden hacer desde el mismo Firebird.

Cúal sería la forma más recomendable, para trabajar?..

Saludos!

[Walter R. Ojeda Valiente]

Primero, debes entender bien el concepto de transacción.

Una transacción es un bloque de código que se trata como una unidad. O sea, se graba toda la transacción en la Base de Datos o nada se graba.

En general, las transacciones las inicia el programador en el lenguaje de su preferencia (por ejemplo, en Visual FoxPro). Sin embargo, el Firebird te permite tener transacciones internas usando para ello el comando IN AUTONOMOUS TRANSACTION. ¿Cuál sería la ventaja de usarlas? que aunque la transacción normal sea desechada con un ROLLBACK, la transacción autónoma igualmente se guardará. Es útil por ejemplo para registrar logs (descubrir errores en tus storeds procedures, registrar quien fue el usuario que realizó tal tarea, etc.)

Todas las transacciones deben finalizar con COMMIT o con ROLLBACK, no hay otra forma. Si no finalizas una transacción (porque te olvidaste de escribir uno de esos dos comandos) esa transacción continuará ocupando espacio en la Base de Datos y a medida que ésta vaya creciendo causará que se vuelva más y más lento el acceso.

En Visual FoxPro si tú no inicias una transacción, él la inicia por tí. Pero en ese caso, con los valores por defecto para las transacciones.

En Firebird, los valores (o parámetros) con los cuales se puede iniciar una transacción son los siguientes:

Acceso a la transacción = READ WRITE, READ ONLY

Aislamiento de la transacción = READ COMMITED, SNAPSHOT, SNAPSHOT TABLE STABILITY

Modo de bloqueo de la transacción = WAIT, NO WAIT

Versión del registro = RECORD_VERSION, NO RECORD_VERSION

Reserva de la transacción = SHARED, PROTECTED, READ, WRITE

Si la memoria no me falla, los valores por defecto son: READ WRITE, SNAPSHOT, WAIT

Así que, respondiendo específicamente a tu pregunta: inicia la transacción desde el Visual FoxPro con los parámetros que para cada caso estimes convenientes.

Saludos.

Walter.

2013/1/24 BD Learner <thenewin...@gmail.com>

Me dicen que las transacciones (en general) se pueden hacer desde el lenguaje (como Visual Foxpro, por ejemplo), pero que tambien se pueden hacer desde el mismo Firebird.

Cúal sería la forma más recomendable, para trabajar?..

Saludos!

--
 
 

--
Hay 10 clases de personas. Las que conocen aritmética binaria y las que no.

[BD Learner]

Excelente Walter!

Agradezco mucho tu magistral explicación. Te prometo guardarla en mis notas, como hice con la explicación que me diste sobre los stored procedures, para consultarla al hacer mis pruebas/desarrollos.

Saludos!

[Walter R. Ojeda Valiente]

Ya que estamos en el tema me explayaré un poco más sobre las transacciones en Firebird.

- Si lo que quieres es realizar una consulta (comando SELECT) te conviene que la transacción sea READ ONLY porque eso hace que la consulta sea un poco más rápida (no mucho más, pero en entornos donde hay decenas o cientos de usuarios la diferencia se notará)

- Todas las transacciones siempre pueden ver todas las filas que fueron "commiteadas" antes de que ellas empezaran. Las transacciones READ COMMITED también pueden ver las filas que fueron "commiteadas" después de que ellas empezaran. En general se usa READ COMMITED en los programas de ABM y SNAPSHOT en las consultas y los informes.

- Nunca una transacción (A) puede ver una fila que fue insertada/borrada/actualizada por otra transacción (B) hasta que la transacción (B) haga el COMMIT correspondiente. Las "lecturas sucias" no están permitidas en Firebird.

- El aislamiento SNAPSHOT TABLE STABILITY es muy drástico porque impide que las otras transacciones puedan insertar/borrar/actualizar filas, aunque siempre podrán consultarlas. En general no se recomienda usar este aislamiento en Firebird. Si lo necesitas lo más probable es que tu lógica esté equivocada.

- Cuando quieres borrar/actualizar una fila y ella se encuentra en uso por otra transacción: si el bloqueo de tu transacción es WAIT, el Firebird esperará hasta que la fila sea desbloqueada. Si es NO WAIT no esperará y al instante devolverá un mensaje de error a tu aplicación.

- En Firebird no se recomienda usar columnas para guardar los saldos. Por ejemplo, tener una columna para saber la cantidad actual de un producto o para saber el saldo que nos adeuda un cliente es un ERROR de concepto.

Saludos.

Walter.

2013/1/24 BD Learner <thenewin...@gmail.com>

Excelente Walter!

Agradezco mucho tu magistral explicación. Te prometo guardarla en mis notas, como hice con la explicación que me diste sobre los stored procedures, para consultarla al hacer mis pruebas/desarrollos.

Saludos!

--
 
 

[BD Learner]

Gracias Walter!

2 preguntas mas:

"- Cuando quieres borrar/actualizar una fila y ella se encuentra en uso por otra transacción: si el bloqueo de tu transacción es WAIT, el Firebird esperará hasta que la fila sea desbloqueada. Si es NO WAIT no esperará y al instante devolverá un mensaje de error a tu aplicación".

Si se diera el caso de una espera infinita.. (quizás por "muerte del servidor de datos").

Si el bloqueo fuera wait o no wait, y por alguna razon las transacciones no fueron grabadas y el FRBD devuelve alguna instruccion de error, ese error se atraparía con las mismas instrucciones que las que atrapan una perdida de conexion?..

(Interesante lo que indicas en tu manual de Firebird sobre enviar la fecha/hora para detectar perdidas de conexion)

Saludos!

[Walter R. Ojeda Valiente]

Justamente el problema del WAIT es que la espera puede llegar a ser eterna. Ejemplo:

- María inició una transacción

- Mientras estaba ingresando datos, la llamó Raúl, su novio y la invitó a almorzar porque tenía que contarle una muy buena noticia

- Como ya era su hora del almuerzo aceptó la invitación

- Él le contó que se ganó la Lotería y la invitó a pasear por Europa, y que el vuelo sale dentro de dos horas

- Ella aceptó encantada y se fueron corriendo hasta su casa para buscar ropas y de allí al aeropuerto

- Y se olvidó totalmente de su trabajo

Todas las demás transacciones que quieran borrar/actualizar las filas que estaba usando la transacción de María serán rechazadas. La única solución en ese caso es detectar el número de la transacción de María y eliminarla, pero algo así solamente lo pueden hacer SYSDBA o el creador de la Base de Datos.

Y si por muy mala suerte, SYSDBA, el creador de la Base de Datos y María son la misma persona, jamás podrán eliminar a esa transacción. Y la Base de Datos irá creciendo, creciendo, creciendo, y cada vez se tornará más y más lenta.

Por eso, algunas recomendaciones:

- Todas tus transacciones deben ser muy cortas

- A todas las transacciones WAIT agregarles la cláusula LOCK TIMEOUT, la cual espera una cierta cantidad de segundos, transcurridos los cuales devuelve un mensaje de error. En general, 5 segundos es un tiempo prudencial en una LAN pero si el acceso es mediante Internet podrías usar 10 o inclusive un poco más.

Los mensajes de error el Servidor los envía a través de excepciones. Las hay de dos tipos:

- Internas del Firebird (por ejemplo, si quieres consultar una tabla que no existe, o insertar un valor nulo en una columna que no acepta nulos, etc., etc.)

- Propias del usuario (por ejemplo, si la fecha de la cobranza es anterior a la fecha de la venta, si se calificó a un alumno antes de que se inscribiera, etc., etc.)

En Visual FoxPro puedes atrapar esos errores (o excepciones) usando la función AERROR()

Y siempre deberías avisarles a los usuarios que falló el bloqueo y que por eso realizaste un ROLLBACK. Y además grabar todos esos errores en un archivo de log para que puedas consultarlos más tarde y descubrir y corregir los inconvenientes.

Saludos.

Walter.

2013/1/24 BD Learner <thenewin...@gmail.com>

Gracias Walter!

--
 
 

[BD Learner]

Jajaja... Walter, te felicito!!

No solamente tienes el conocimiento sino también eres una de las pocas personas en la tierra que sabe enseñar, que tiene didáctica.

Tu deberías trabajar en Harvard, Standford, Berkeley (u otras UC) o Cambridge. 

http://www.universityofcalifornia.edu/campuses/welcome.html

Serías un profesor muy bien pagado. Has pensado en ello?..

Saludos!

[edgar suarez kummers]

Buenos Días Walter:

Deberías a mi juicio reintegrarte al foro, donde tienes cientos de programadores que admiran tu trabajo y conocimientos.

Estas mismas explicaciones frente a un auditorio numeroso justifican tus años de dedicación.

No creo que LMG lo pueda hacer por tí, aunque en el fondo debe reconocer tu talla.

Please look my LINKS --- What I offer ---

CLICK my (mi) software offer (oferta)

CLICK para leer acerca del generador de aplicaciones para PLC

CLICK to read about the PLC software generator

edgar suarez kummers

cel: 57-3176992038

tel fijo Bogotá: 2493100

--
 
 

[Walter R. Ojeda Valiente]

Gracias Edgar, pero ya no me interesa regresar al grupo de VFP.

Era una gran pérdida de tiempo para mí (y como sabes: tiempo es dinero). Mayormente me dedicaba a ayudar a los compañeros o a discutir con los idiotas de ese grupo (ejemplos: Luis Mata, Juan Salvador, el Juan Pablo zambo, etc.)

En un día normal lo que sucedía era lo siguiente: estaba trabajando con mis aplicaciones, veía que llegaba un mensaje al grupo de VFP, revisaba el mensaje, si era un tópico que consideraba de interés lo leía, a veces lo respondía, mientras tanto llegaban más mensajes, de nuevo a repetir el proceso, luego continuaba con mi trabajo pero desconcentrado, llegaban más mensajes, etc.)

Sinceramente, Luis María me hizo un favor inmenso al expulsarme de ese grupo. En los dos meses o algo así transcurridos desde mi expulsión creo que he ganado más dinero que en todos los diez meses anteriores, la diferencia en mis ingresos es muy notoria porque ahora trabajo sin distraerme y por lo tanto soy muchísimo más productivo. En pocos meses más podré darme lujos impensables un año atrás.

En lo que respecta a Bases de Datos, a Firebird, a Análisis de Sistemas o a cualquier otro tema similar seguiré ayudando porque las preguntas son muy esporádicas y el tiempo que me quitan es muy poco, pero ya no responderé preguntas relacionadas con Visual FoxPro, ésas se las pueden hacer a Luis María o a algunos de los otros "próceres" que se alegraron con mi expulsión.

Saludos.

Walter.

2013/1/24 edgar suarez kummers <edgark...@gmail.com>

[Jose Ramon Veliz Martinez]

Hasta ahorita me desayuno que te habian expulsado Walter. Increible. Con razon ya no veia mas tus comentarios.

Bueno en lo personal te felicito por tus conocimientos pero mas por brindarlos como tu dices, solo recibias las gracias y felicitaciones del grupo. Yo si que no sabia nada de bases de datos, hasta que baje tu manual de FIREBIRD y tu programa de inventario y lo estuve estudiando.

Aprendi mucho gracias a vos, no tengo el dinero para pagartelo, asi que solo gracias de nuevo y felicitarte por tu forma de ser y no cambies y que no te hagan cambiar. Esa es la actitud.

Todavia no he realizado ninguna aplicacion con FIREBIRD, porque paso con demasiado trabajo y saliendo del pais. Pero pronto hare una y tendras tu reconocimiento.

Gracias de nuevo

[Walter R. Ojeda Valiente]

Hola José

Pues sí, así fue, sin explicaciones, nada de nada. Pero bueno, así se conoce a la gente.

Con respecto a Firebird, el 2 de marzo creé un blog y le agrego al menos uno o dos artículos cada día por lo tanto siempre hay algo nuevo por allí. La dirección es:

http://firebird21.wordpress.com

Si te interesa suscribirte, abajo y a la derecha de cada página verás un botón que dice "Seguir", si haces click allí y pones tus datos, recibirás un e-mail cada vez que publique un nuevo artículo.

Si algo no entendiste bien o si quieres que escriba sobre algún tema en especial, sólo tienes que pedirlo.

Saludos.

Walter.

2013/5/14 Jose Ramon Veliz Martinez <spc.j...@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "Sistemas Gestores de Bases de Datos" de Grupos de Google.
Visita este grupo en http://groups.google.com/group/sistemas-gestores-de-bases-de-datos?hl=es-419.