Cuando un
registro del un archivo queda “bloqueado”
por el mismo job que está ejecutando la
aplicación, se genera un mensaje de error que es incomodo para la mayoría de
los programadores.
El trabajo “bloquea
el acceso” a un registro y luego intenta accederlo en alguna operación de
Update mas adelante; el tiempo de espera
se agota y se produce el desconcertante mensaje:
“El
registro ya está asignado en este trabajo”.
¿Cómo hice para que mi
programa bloqueara el acceso a un registro que él mismo está procesando?.
Un caso en
el que se produce este incomodo error es el siguiente.
Supongamos
que hacemos una declaración de este tipo en la hoja F
FDirpfl001 uf a e k disk
Tenemos un
archivo de tipo UPDATE que además permite adicionar registros.
Generalmente
llenamos el Subarchivo con un lazo que recorre el archivo declarado en la hoja
F y lo va “vaciando” en cada registro del subarchivo en pantalla:
setll
*loval dirpfl001; // se posiciona al
principio del archivo
Read
Dirpfl001; // lee
el primer registro
Dow not
%eof(dirpfl001);
Dsp_Cedo =
Aescod; // Llena los campos
Dsp_Des =
Aesdes; //de pantalla
Rrn = Rrn +
1; //graba en
write fmtsfl; //
el subfile
Read
Dirpfl001; //lee el siguiente registro.
enddo;
La
declaración del archivo como UPDATE, tiene el efecto de que cada lectura que se
hace sobre el archivo “retiene” el registro hasta que se produzca la lectura de
otro registro o se realice un UDPATE sobre el mismo. El último registro que se ha leído para
llenar el subarchivo ha quedado “bloqueado” puesto que no le sigue la lectura
de otro registro ni se ha realizado una operación update sobre este último
registro.
El usuario
puede seleccionar este registro para hacer update, luego de realizar los
cambios pertinentes en pantalla. El programa trata de realizar una operación CHAIN
sobre este registro y se produce el pavoroso error que deja al programador
desconcertado.
El último
registro leído no es el único caso de riesgo para la aparición de este error. Cualquier
lectura de consulta que se realice sobre un registro mostrado en la pantalla implica
generalmente un CHAIN al registro; se muestra el detalle de la data y luego el
usuario decide o no modificar la información. Si el usuario se queda en el nivel de consulta,
todo marcha bien, pero si el usuario decide modificarlo luego de haberlo
consultado. EL registro ya fue retenido con un read previo al hacer la consulta
e inevitablemente al querer accederlo nuevamente para hacer un UPDATE, se produce el error de acceso al registro,
haciendo que el programa falle por tiempo de espera agotado.
¿Cómo resolver este problema?
Al realizar
una consulta sobre un registro o al llenar el subfile de la pantalla, debe
realizarse la lectura del archivo adicionando un (N) para impedir que el
registro sea retenido en cada lectura (read.) Este bloqueo automático sucede
por haber declarado el archivo de UPDATE aún cuando solo estemos leyendo el
archivo. Entonces para impedir que el bloqueo automático sea activado en cada
lectura, se indica una (N) al lado del Read o chain que evitará este
inconveniente. Reescribiendo la rutina de llenado del subfile quedaría lo
siguiente:
setll *loval dirpfl001;
// se posiciona al principio del archivo
Read(n) Dirpfl001; // lee
el primer registro
Dow not
%eof(dirpfl001);
Dsp_Cedo =
Aescod; // Llena los campos
Dsp_Des =
Aesdes; //de pantalla
Rrn = Rrn +
1; //graba en
write fmtsfl; //
el subfile
Read(n) Dirpfl001; //lee el siguiente registro.
enddo;
Cuando va a
realizarse efectivamente la actualización del registro con la combinación:
Chain-update o con la combinación
read-update no debe colocarse la (N)
en la lectura (read o chain) puesto que en ese punto si nos interesa que el
registro esté bloqueado para que se realice el UPDATE correctamente.
Si te pareció
interesante, reenvíalo a un amigo haciendo click en el sobrecito que está al
final del artículo. El conocimiento es valioso, compártelo.
Autor: Ing. Liliana Suárez
Autor: Ing. Liliana Suárez
