Buenas noches

    Estoy al fin de vuelta por aquí. Os traigo una duda, no se si es el subforo indicado, yo la lanzo y si decidís cambiar de sitio la pregunta, sin problemas. Allá voy, espero explicarme bien.

    El caso es que estoy haciendo una aplicación que usa una BBDD MySQL. La aplicación funciona en red, de modo que muchos usuarios pueden conectarse a esa misma BBDD y hacer cambios en ella. La duda surge cuando varios usuarios están 'tocando' información en la BBDD que está relacionada entre sí. Por ejemplo:   El usuario A está modificando los datos de un cliente, mientras el usuario B está haciendo una factura a ese cliente.

    Imaginemos que B fue el primero, abrió un formulario y obtuvo datos del cliente. Luego A viene y modifica los datos del cliente. Cuando B, que tiene los datos del cliente 'sucios, no actualizados respecto a  la BBDD' va a guardar la factura, ¿qué proceso se sigue? ¿Cual es el protocolo habitual? Se le dice a B que alguien modificó datos del cliente? Se guarda la factura sin decir nada?

    Fundamentalmente estoy perdido porque ya no solo es una cuestión técnica, sino que no se cual es el proceder habitual de las aplicaciones en RED por lo que no se como actuar.

    Aparte de esto, también debo revisar el tema de transacciones y bloqueos, aunque eso si que lo tengo controlado. Mi problema se da cuando un usuario tiene datos 'sucios, 'no actualizados' en el formulario y se dispone a guardarlos como si esos datos fueran reales pero ya no lo son.

    Espero no haberos liado. Toda la documentación sobre el tema me vendría de perlas. Busco en google pero solo encuentro información de bloqueos y transacciones en la BBDD, pero nada de como manejar el programa.

Un saludo

===================
Proyecto Open Media Manager -> http://www.OpenMediaManager.com

netking86:

Se me ocurre que el programa haga una comprobación de los datos que vaya a guardar, por si se ha modificado algo, lo avise al usuario...

Del ejemplo que pones, supongo que los datos vienen de distintas tablas ("compras" y "datos de la empresa a facturar"), por lo tanto si estas el usuario B, esta modificando los conceptos de compra de la factura, aunque se modifiquen los datos de la empresa,  por el usuario A, "no se ve perjudicado" aunque visualmente si tenga datos distintos. Pero a la hora de imprimir deberás de leer todos los datos de la base de datos "de nuevo", entonces todo se va a actualizar a los últimos cambios. (El problema puede venir si vas a imprimir, sin leer de nuevo los datos de la base de datos, con los datos que tienes en tu formulario relleno, y por lo tanto las ultimas actualizaciones no las tienes.)

Distinto es, que varios usuarios, esten modificando datos  de las compras de una misma factura... ahí si que puede dar problemas... por lo tanto si tendrias que emplear bloqueos, para impedir que varios usuarios esten trabajando en la misma factura.

Seguro que Shordi, puede orientarnos más sobre este tema...

Saludos

Julio

===================
Blog personal
Web: SoloGambas seleccion de articulos dedicados a Gambas
Visita el Curso de Gambas3 ¡¡¡Gratuito!!!

Gracias jsbsan!

   A ver, entiendo lo que dices de comprobar antes de guardar. Imagino que haré algo así y que en caso de modificación externa, te permita sobrescribir/cargar los nuevos datos de la BBDD/salir.

   En cuanto a los bloqueos, ahí si que tengo dudas SERIAS. He leído sobre transacciones. Entiendo que hacen las instrucciones atómicas, pero aparte de estas transacciones necesito hacer bloqueos? O sea, dicho de otro modo, dada una tabla, si hago un UPDATE o un SELECT de '1 linea', es necesario gestionar el bloqueo? O eso lo hace MySQL por nosotros?

   La cuestión es que no se si los bloqueos se usan cuando trabajas con un conjunto de instrucciones MySQL y en ese caso se usan transacciones o bien si los bloqueos deben usar en todas las instrucciones, sean o no atómicas.

   Todo esto es para un programa Visual Studio que se comunica con uno en gambas. Si me pudieseis ilustrar os estaría ETERNAMENTE agradecido.

Un saludo!

===================
Proyecto Open Media Manager -> http://www.OpenMediaManager.com

Por cierto, caigo ahora en la cuenta...

   Si antes de guardar debo hacer una comprobación, imagino que necesitaré hacer un bloqueo justo antes de esa comprobación ¿no? Porque podría comprobar, ver que todo va en orden y justo ahí entrar otro usuario y pisarme información. Lo dicho, ¿esto se hace con transacciones o es necesario mirar el tema de los bloqueos?

Gracias de nuevo, un saludo

===================
Proyecto Open Media Manager -> http://www.OpenMediaManager.com

Hola de nuevo, os cuento el avance (muy pequeño) que he hecho

  He probado la transacción y va genial. Un tema muy útil. Lo que me gustaría ahora es bloquear la tabla/s implicada/s para poder:

 1. Hacer comprobaciones sobre si su inserción es adecuada
 2. En caso de error, hacer rollback e interactuar con el usuario
 3. En caso de éxito, hacer la transacción

  El problema que tengo es que probando LOCK TABLE, abro una instancia de la aplicación y si que puedo modificar las tablas supuestamente cerradas.

Aparte de eso, tengo unas dudas:

  1. ¿Una vez inicio una transacción, si hago modificaciones y posteriores consultas, en esas consultas son visibles las modificaciones que se han hecho en la transacción hasta ese momento? O veo una imagen de la tabla en el momento del inicio de la transacción?
  2. Al hacer el LOCK TABLE, el bloqueo se hace para una IP? Para un PC? Para una conexión? Me explico, con dos instancias de la Aplicación puedo probar que funciona correctamente?
  3. Es muy ineficiente el bloqueo de tablas?
  4. Además de INSERT Y UPDATE, ¿se debe hacer con SELECT para tener una lectura limpia?

Gracias!

===================
Proyecto Open Media Manager -> http://www.OpenMediaManager.com

Buenas a todos, siento ser tan pesado

He avanzado algo más. Parece que si el bloqueo de la tabla lo hago DENTRO de la transacción este funciona. La escritura 'remota' espera a que yo termine mi transacción y entonces hace su UPDATE, SELECT o lo que toque.

Así que solo me quedan dos cuestiones:

 - Es muy ineficiente el bloqueo de tablas?
 - Además de INSERT Y UPDATE, ¿se debe hacer con SELECT para tener una lectura limpia?

Un saludo

pd. Siento tantas ediciones, pero no soy de los que esperan a que alguien el enmiende la duda

===================
Proyecto Open Media Manager -> http://www.OpenMediaManager.com

Los bloqueos a nivel de tabla son "muy bestias" si lo que tú modificas es un registro. Yo no los usaría. Utiliza el motor de datos InnoDB dentro de Mysql (el que viene por defecto es MyIsam) y tendrás la posibilidad de bloquear a nivel de registro (además de integridad referencial, etc. etc.) Para mí MySQL no tiene sentido sin InnoDB.

De todas formas no te comas demasiado el tarro, las concurrencias, salvo mal diseño del programa, no suelen ser problema. A veces ocurren, pero no suelen ser nada grave...
Bloquear al leer tiene sus problemas, por cuanto el usuario puede recuperar un registro con lo que lo deja bloqueado y luego se va a tomar un café, etc. Eso hace que tengas que implementar time-outs en los formularios, etc. etc.

Si prefieres hacer los bloqueos a nivel de código tuyo, sólo tienes que añadir dos campos a cada tabla, uno llamado usr -por ejemplo- en el que se grabe automáticamente el nick del usuario que añade/modifica un registro y otro fmod de tipo TIMESTAMP que se actualice en el momento que se modifique (opción ON UPDATE CURRENT_TIMESTAMP que cambia su valor automáticamente, si no recuerdo mal). Sólo tienes que guardar valor de fmod en alguna variable al leerlo y compararlo justo antes de grabar, si ha cambiado, envias un aviso al usuario, si no actualizas y punto.
No sé si te ayudo o te lío...     

Saludos

Hola Shordi!

 Ayudas, ayudas

Citar:

Utiliza el motor de datos InnoDB dentro de Mysql (el que viene por defecto es MyIsam) y tendrás la posibilidad de bloquear a nivel de registro (además de integridad referencial, etc. etc.) Para mí MySQL no tiene sentido sin InnoDB.

Con esto te refieres al tipo de tabla? Yo gestiono la BBDD con un software llamado Navicat y en el listado de tablas vienen todas como InnoDB. Es eso o es algo más complejo? Qué comando SQL bloquea a nivel de registro?

Citar:

Bloquear al leer tiene sus problemas, por cuanto el usuario puede recuperar un registro con lo que lo deja bloqueado y luego se va a tomar un café, etc. Eso hace que tengas que implementar time-outs en los formularios

Cuando me refiero a bloquear en la lectura es para rellenar una lista de registro u obtener uno, pero una vez leído desbloquearía. No es el clásico bloqueo pesimista de Access y Visual Basic 6. Solo hablo de leer una consulta y cargarla en una lista

Citar:

Si prefieres hacer los bloqueos a nivel de código tuyo, sólo tienes que añadir dos campos a cada tabla, uno llamado usr -por ejemplo- en el que se grabe automáticamente el nick del usuario que añade/modifica un registro y otro fmod de tipo TIMESTAMP que se actualice en el momento que se modifique (opción ON UPDATE CURRENT_TIMESTAMP que cambia su valor automáticamente, si no recuerdo mal). Sólo tienes que guardar valor de fmod en alguna variable al leerlo y compararlo justo antes de grabar, si ha cambiado, envias un aviso al usuario, si no actualizas y punto.

Esta parte si que la iba a hacer así. Porque si no, como dices, es incontrolable que el usuario se vaya y me deje colgado el software. Con el bloqueo para las lecturas solo me refiero a cargar una lista como he dicho antes.

Muchas gracias a todos, un saludo

===================
Proyecto Open Media Manager -> http://www.OpenMediaManager.com

Para cargar una lista ni te molestes. El gestor de la base de datos tarda unos pocos milisegundos en hacerlo. Es rarísimo que te coincida con una actualización y, si bloqueas durante una décima de segundo y luego desbloqueas y el usuario te actualiza en la décima de segundo siguiente, el resultado sería el mismo. O sea, que no vale la pena. Los bloqueos resérvalos para las modificaciones, o masivas (copias de seguridad) o puntuales.
Sobre InnoDB hay mucha información en la red. Échale un vistazo y verás las ventajas.
¿Cómo solucionar el coffee problem? Pues o implementas un time-out de inactividad en el formulario (más follón, pero en el foro hay algún que otro ejemplo que subí hace tiempo) o simplemente compara antes de grabar si el timestamp sigue intacto. Si no es así, no grabes y da un aviso al usuario.

Saludos

Comentario:

Siempre estais hablando del motor de bases de datos de MySQL a la hora de que lo usen  múltiples usuarios, pregunto:

¿ con sqlite, se puede trabajar con varios usuarios?
Yo he hecho algunas pruebas, compartiendo la carpeta donde estaba la base de datos en la red,  y funcionaba.. pero claro son pruebas y no es un ambiente de "producción"....

===================
Blog personal
Web: SoloGambas seleccion de articulos dedicados a Gambas
Visita el Curso de Gambas3 ¡¡¡Gratuito!!!