* Original message posted in: sk-clipper.
* Crossposted in: progclub, clipper.
         Con la llegada de Clipper 5.2 (casualmente en el transpaso de 
Nantucken a C.A.) la forma que ten¡a de trabajar Clipper con el tema de 
lockeos y manejo de archivos ¡ndices era transparente, pero con esta versi¢n 
(5.2 y ahora 5.3) la forma de laburar con los ¡ndices es esta...  Supongamos 
que hay 3 terminales y las bases est n en el server.  Bueno, el terminal #1 
abre una base (shared) que tiene un ¡ndice, y la browsea.  Bueno, cuando la 
browsea sucede esto.  Clipper internamente con cada movimiento del cursor en 
la base, lockea el .NTX/.NSX/.etc... por un lapso m¡nimo que no llega al 
segundo, cosa que no hac¡a el 5.01! ¨Porque? es la pregunta... Hay alguna 
forma de impedir que el clipper en s¡ no haga esto?  El porqu‚ de mi pregunta 
es esta... El terminal #1 abre la base (con su correspondiente ¡ndice) y la 
browsea (con su correspondiente lock/unlock de menos de 1 seg.), pero se une 
el terminal #2 y el #3 que hacen lo mismo.  Supongamos que no son solo 3, 
sin¢ 60 terminales....  ¨Que suceder¡a si cuando el terminal X# browsea, el 
clipper en s¡ pide el lockeo pero la red est  muy pesada y el pedido del 
lockeo llega bastante mas tarde de lo esperado y el usuario dice... "pucha, 
se colg¢.... RESET"?  El pedido de lockeo fu‚ hecho, pero ete aqu¡ que el 
pedido de deslockeo (tambien mandado por el clipper) no fu‚ mandado.... Que 
obtenemos? Un .NTX lockeado y por consiguiente las dem s terminales quedan 
congeladas esperando que se deslockee el .NTX , cosa que no har , porque esa 
m quina ya fu‚ patapufeteada por el user....   En fin... que respuesta se le 
puede encontrar a esto?
                                               -=[ Sk-NetWork Argentina ]=-
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Sk-NetWork(c) Software  ù . ú . ù La Primera Red dedicada a la PROGRAMACION
--- 
---------------