Ambiente Multi-Usuario

[Bayron]

Todavia no termino de comprender en mi mente, que es lo que sucede en un ambiente multiusuario...
Me imagino que usado un DBF, el RDD se encarga de la mayor parte del proceso usando DBLOCK() y DBUNLOCK(), pero que pasa en ambiente MYSQL o SQL en general???

Usando tDolphin, entiendo que un SELECT se encarga de obtener los registros que coincidan con una condicion...

Pero, Que sucede cuando estos registros son modificados por otro usuario????

Sucede lo mismo en ambiente PHP???

Que sucedería en el siguiente caso:

El dueño de una Empresa cuenta con dos usuarios...

Solicita al usuario 1 que aumente los precios de los productos un 5%...
El usuario, ejecuta la accion, para ello el programa ejecuta el SELECT, la informacion de es colocada en los respectivos get,
pero tiene que ir al baño por 15 minutos, sin haber guardado la informacion...

Luego, el dueño decide mejor aumentar los precios un 25% y como no localiza al usuario 1, le pide al numero 2 que realize el cambio...
Cuando el usuario 1 regresa, sin conocer la situacion, guarda la informacion que el habia editado...

La pregunta es: Qué pasa con la informacion desde el SELECT hasta que es almacenada, supongo usando un BEGIN - END SEQUENCE???

[Daniel Garcia-Gil]

Byron

los datos que estaran en las tablas dependeran de la ultima accion que influya en la modificacion de la mismas, sea un insert, update o delete

simplemente si el usuario 1 no actualizo la informacion y otro usuario lo hizo, al usuario 1 guardar lo que tiene pendiente se "perderan" los datos guardados de 2...

[Bayron]

Gracias Daniel,

Ya se me va alumbrando el foco...

para esto se me ocurre entonces, una comparacion del dato obtenido originalmente con el dato actual de la base de datos antes de guardar la información....

Ahora, que pasa con el contenido de algún xBrowse por ejemplo, si los datos son modificados por otro usuario????
tDolphin actualiza automáticamente el contenido del xBrowse al momento de ser actualizados por otro usuario sin necesidad de hacer un refresh???

[Daniel Garcia-Gil]

Bayron

Ahora, que pasa con el contenido de algún xBrowse por ejemplo, si los datos son modificados por otro usuario????
tDolphin actualiza automáticamente el contenido del xBrowse al momento de ser actualizados por otro usuario sin necesidad de hacer un refresh???

No, TDolphin no es la "limitante" sino MySql, En conexiones remotas no se leen los datos de la tabla fisica sino que se leen por una sentencias SELECT, esta consulta es guardada en el servidor con los datos tal cual estaban en ese momento, esa consulta es administrada por un handle que nos envia MySql con su API, si existe un cambio en los datos de la tabla despues de generar la consulta es obligatoria rehacer la consulta (refresh)
MySql no maneja notificaciones de manera que le envia a los clientes conectados

[Bayron]

Solo por curiosidad:

Esto mismo sucede con archivos DBF???

O xBrowse administra las actualizaciones automáticamente???

[Daniel Garcia-Gil]

Bayron

con las dbf lees directamente del archivo fisico, es decir, cuando lees lo haces directamtente del archivo, mientras con mysql haces una peticion remota y en base a esa peticion mueves el puntero a travez de los registros (pero de la consulta no del archivo fisico)

[Bayron]

Gracias Daniel, como siempre tu explicación es muy concisa...

[sysctrl2]

para la tecnologia SQL,

puedes implementar un TIMER,

que haga un oQry:Refres(), oBrw:Refresh() cada determinado segundos o milesimas de segundos.

aunque se me ocurre , Daniel, Antonio, que tan dificil seria

agregar un nuevo METHOD al xBrowse, algo como

oBrw:lTimer := .t.

jeje solo es ocurrencia no se si se pueda .

saludos..

[MarioG]

Permiso
Quisiera me amplien sobre el primer ejemplo. Porque Daniel bien explica lo que ocurre, aunque lo que quisiera saber es como controlar tal situación.
Para el caso de las DBF existe el bloqueo. He leido, pero no puesto en práctica, que MySQL tambien implementa bloqueos. Es para el mismo efecto?.
Pero repito, para el caso del primer ej. de Byron, cual es la mejor solución?

gracias
Mario

[jbrita]

Amigos en Sql, no se si estoy equivocado pero se podria usar un campo por tabla ejemplo q diga bloqueo.
que cuando un usuario lo tome lo ponga en .T., asi los demas cuando entre a ese registro preguntar si bloqueo esta .F. entran y si esta .T. ocupado algo asi.

Saludos

[FranciscoA]

Amigos, veamos lo siguiente:
El caso expuesto por Byron se traduce a una falta de disciplina de parte del usuario 1. Imaginemos cuanto tiempo nos cuesta encontrar el codigo del producto y modificar solo el valor del get que contiene el precio... pero, bueno, sucede a menudo. Le sumo a falta de disciplina, negligencia, porque este hecho puede ocasionar que se vendan productos a un precio menor al que la gerencia o dueño del negocio acaba de establecer.

Una posible solución, la de sysctrl2, es usar un Timer que ejecute la acción de cerrar el dialogo después de un tiempo prudencial sin eventos. Sin embargo, si el usuario 2 hace la modificación, al regresar el usuario 1, aunque encuentre cerrado su dialogo, si este (usuario 1) no recuerda, no conoce, o no se fija en el precio (que ya fue cambiado), ejecutará la modificación que le encomendaron. Los resultados ya se saben: alteración al precio recién modificado.

Para este caso, ademas del Timer, se tendría que llevar un control sobre el registro que se está modificando o que fué modificado (y en qué fué modificado), para que cuando otro usuario entre en la opción MODIFICAR de este registro, se puedan presentar mensajes al respecto. Aquí cabe algo parecido a lo que expone jibrita, crear un campo "MODIFICADO" que contenga información sobre la última modificación. También se puede utilizar trigers, u otra tabla independiente. La idea es que cuando otro usuario entre a modificar el registro, se le presente esta información. En este caso se puede usar el siguiente pseudo-codigo: Si MODIFICADO="Modificando", MsgStop("Estoy siendo modificado por otro usuario"), MsgInfo("Esta es la ultima modificacion"). Por supuesto, de previo debe llevar la condición de que este campo está vacío o no.

La idea de bloquear el registro, no es aconsejable en este caso, porque lo mantendríamos bloqueado mientras el usuario 1 se toma su cafecito, o sale del baño, y mientras tanto, no puede ser editado por otro usuario. En DBFs uso el bloqueo hasta oprimir el botón ACEPTAR. En MySql no los he usado.

En mi sistema de contabilidad tengo implementado un control de documentos en edicion, donde controlo el No. de documento, usuario, y equipo. De esta manera evito que otro usuario pueda intentar editar el mismo documento, a la vez, o que el usuario original trate de abrirlo mas de 1 vez.

Problemas en un entorno multiusuario o red, no nos faltarán. Sin embargo, para todo hay solución con un poco más de codificación.

Espero no haber "enredado el asunto".

Saludos.

[jbrita]

Francisco en los dbf asi funcionan los bloqueo

Saludos

[Bayron]

La idea de usar un campo para guardar si se está usando la tabla o determinados campos no puede ser válida, porque podría darse el caso de que la información en dicho campo no sea real, en caso haya habido por ejemplo un apagón y el campo quede marcado como si alguien lo estuviera usando... No se puede bloquear un campo por mucho tiempo, porque causaria caos...

El ejemplo que yo he colocado, es solamente como decimos por aquí: UN SUPOSITORIO (un supuesto), o sea un caso que pudiera darse...
Y ya que yo nunca he trabajado con ambientes multiusuario, quisiera comprender como es que se trabaja....

El mayor problema que se da al trasladarse de DBF a SQL es, pienso yo, cosillas como estas, que dabamos por sentadas con archivos DBF y no tenemos idea de como proceder con SQL

SQL es otra cosa, aunque yo se, que no es cosa del otro mundo...

Yo nunca he desarrollado ninguna clase de aplicacion completa, solo hago programillas para probar o por diversión, pero me gusta comprender las cosas por si algún día tengo que utilizarlas...