FoxPro/Visual FoxPro - pasando aplic monousuario a red

Hola la aplicacion en cuestión es realizada en FoxPro 2.5a para DOS. Para abrir las tablas tengo set exclusive off.
Como soy nueva tengo varias dudas.

En las consultas eliminé las tablas por cursores o tablas temporales.

1) Estuve viendo el Help, y dice que los cursores se comportan como tablas, pueden indexarse,
borrar registros, inserar, etc. Pero mi experiencia es que a un cursor producto de una query SQL,
me dijo al intentar indexar que era solo read-only. Lo sustitui por una tabla y listo, pero ¿qué hice mal?

Código:

Create Cursor cursorX

select a, b
form tablaX
into cursor cursorX

2) para las consultas en algunas temporales se las vaciaba mediante ZAP, el código era el siguiente:

Me valgo de 2 funciones auxiliares, que lo que hacen es hace un lock a un archivo señuelo y no a la tabla propiamente dicha. La tabla se llama "candado", cuando está lockeada no puede accederse al resto

PROCEDURE CANDADO_ON
UNLOCK ALL
IF !USED("CANDADO")
USE CANDADO IN 0
ENDIF

PRIVATE XSR
XSR=SET("REPROCESS")
SET REPROCESS TO 1
DO WHILE !FLOCK("CANDADO")
DO CINFORME WITH "Los archivos est n en uso...\n\n"+;
"Toque ENTER para reintentar ya, o espere a que esta "+;
"ventana se vaya y reintente sola.",2
ENDDO
SET REPROCESS TO (XSR)

PROCEDURE CANDADO_OFF
UNLOCK ALL

Luego el procedimiento es :
=CANDADO_ON()

SELECT _file
DO WHILE !FLOCK() && Asegura disponer de
ENDDO && los últimos datos
UNLOCK && en ambiente de red

APPEND/INSERT/ZAP && lo que corresponda
=CANDADO_OFF()

El zap me trajo problemas: "File access denied"...¿prevalece el zap sobre el lock?

Gracias, rossana

El detalle es que no puedes dar zap

si no tienes exclusiv on en tu tabla..

es decir USE TuTablaTemporal IN 0 EXCLUSIV

ZAP

SUERTE

1- Desde la version 7 en adelante un cursor que sea creado mediante un SELECT -SQL puede escribirse con solo agregar la clausula READWRITE.

- En foxpro 2.6x lo que necesitas hacer es crear un cursor con CREATE CURSOR y vaciar el contenido de tu cursor a este nuevo cursor

2- El Zap es un comando peligroso. Si esa tabla te falla es posible que se aplique a otro. La repuesta a tu pregunta es NO.

Hola, gracias por sus respuestas, bueno en el Help de la versión que tengo para trabajar, no tiene la opción READWRITE en la sintaxis.
Sí, opté por sustituir las tablas por cursores por su carácter temporal.

Disculas, pero no entendí esto: "El Zap es un comando peligroso. Si esa tabla te falla es posible que se aplique a otro"
La tabla a la que se le aplica ZAP es abierta con EXCLUSIVE,y en modo monousuario no hay problemas, pero sí cuando se accede de forma concurrente.
Pensé que al aplicar EXCLUSIVE eso ya 'invalida' al otro usuario, aunque este haya liberado el recurso (Candado_off).

Saludos

Te dije que READWRITE esta disponible desde la version 7 en adelante.

Por que te digo que el ZAP es un comando peligroso, a mi me llego a pasar lo siguiente

SELECT 1
USE tabla1

SELEC2
USE tabla2 &&Suponiendo que tuve un error aqui

ZAP &&El zap se le aplica entonces al ALIAS que este activa, en este caso la 1

sí para la versión 7 entendí, pero me fijé porque el Help y el manual decían que se podía, evidentemente es un error que comprobé empíricamente.

ahora entendí lo que me decías sobre el ZAP, no se si se aplica a mi caso, pero veo que puede ser errático.
En mi caso intenté variantes con SET REPROCESS, etc, pero no había caso, no dejaba. Viendo el código a la tabla a la que se le hace ZAP es usada para cargar datos que va a un reporte, por lo cual al ser abierta con EXCLUSIVE (para poder hacer ZAP), quizás no queda disponible al otro usuario.

Quería saber si esto era posible. gracias por tu ayuda, saludos

por lo cual al ser abierta con EXCLUSIVE (para poder hacer ZAP), quizás no queda disponible al otro usuario.

asi es si tu abres una tabla para un proceso usando la clausula EXCLUSIVE no podra ser abierta por otro proceso

si, eso temía, muchas gracias
saludos, rossana

ok
suerte