FiveTech Support Forums

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...

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???

Bayron wrote: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???

Solo por curiosidad:

Esto mismo sucede con archivos DBF???

O xBrowse administra las actualizaciones automáticamente???

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)

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

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

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

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.

Francisco en los dbf asi funcionan los bloqueo

Saludos

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...