Tweet
PB 3.2 for DOS.
Quite a number of years ago, before I had e-mail, I enquired by
telephone (I spoke to Lloyd Smith on several occasions) on the
question of file locking on a network. Many words were exchanged, but
ultimately I was given "Access READ WRITE SHARED" as the combination
which gives neither compile time nor run time problems. The kdd$ below
is a path.
Open kdd$+"DEBTORS" Access Read Write Shared As #7 Len=450
field #7, 30 As dco$, 8 As ddt$,20 As dcp$,15 As dtl$,15 As dfx$
field #7, 88 As z$, 15 As dtx$,15 As dvt$,30 As dp1$,30 As dp2$
field #7,178 As z$, 30 As dp3$,30 As dp4$, 6 As dx1$, 6 As dx2$
field #7,250 As z$, 10 As dcr$,10 As d30$,10 As d60$,10 As d90$
field #7,290 As z$, 10 As d20$,10 As d50$,10 As d80$, 5 As dtm$
field #7,325 As z$, 5 As dtd$, 5 As din$, 2 As dpw$,20 As dct$
field #7,357 As z$, 10 As dlm$,24 As dsr$,15 As dar$,10 As dua$
field #7,416 As z$, 1 As dcx$,10 As dob$, 3 As dlv$, 4 As dqn$
field #7,434 As z$, 5 As dkm$, 4 As dsd$, 3 As dxx$, 4 As dun$
All logic aside for the moment, this has been running for about seven
years (ALL files being opened in this fashion) at a number of user
sites. What problems there were, were very rarely disk file related,
and by far the most were simply due to the odd condition not catered
for.
Now, in response to a user enquiry (they had encountered file
corruption in a known set of circumstances), I have tried to use:
To only READ, and permit other workstations to also read, but not
write --
Open kdd$+(filename) Access READ Lock WRITE As #x
To read AND write, as when file maintenance is performed, and permit
other users NO access to the record --
Open kdd$+(filename) Access READ WRITE Lock READ WRITE As #x
In all cases only RECORDS are locked before access and immediately
afterwards unlocked, except in the case of "maintenance" (read/write).
The file is closed as well, except in the "read write" case, where
this is not done until the record has been refiled and unlocked.
Only the two modules in question were modified in this way and sent
to the user site, with interesting results. Now, when two workstations
both use the "read" only (no write) module, and one of these selects
an account from the menu AND accesses that account and stays there,
then, when the second station tries to select one likewise (a different
record), an error 70 (access denied) occurs, and it keeps on retrying,
using RESUME. The moment the first station exits its record and returns
to the menu, the second user immediately gains access. All this when
only RECORD locking is used, as in --
da%=dr%(sb%+op%-1)
Lock #7,da%
Get #7,da%
UnLock #7,da%
Is there a hole in the logic, or is it twisted logic? The PB examples
do describe these things, but then proceeds to give examples with no
file or record locking illustrations.
What is the correct way in the various combinations of Access READ
and/or WRITE and Lock READ and/or WRITE situations? There are random,
binary and a few sequential files involved. The binary files are locked
"from/to byte". In the case of sequential files the whole file is
locked.
Quite a number of years ago, before I had e-mail, I enquired by
telephone (I spoke to Lloyd Smith on several occasions) on the
question of file locking on a network. Many words were exchanged, but
ultimately I was given "Access READ WRITE SHARED" as the combination
which gives neither compile time nor run time problems. The kdd$ below
is a path.
Open kdd$+"DEBTORS" Access Read Write Shared As #7 Len=450
field #7, 30 As dco$, 8 As ddt$,20 As dcp$,15 As dtl$,15 As dfx$
field #7, 88 As z$, 15 As dtx$,15 As dvt$,30 As dp1$,30 As dp2$
field #7,178 As z$, 30 As dp3$,30 As dp4$, 6 As dx1$, 6 As dx2$
field #7,250 As z$, 10 As dcr$,10 As d30$,10 As d60$,10 As d90$
field #7,290 As z$, 10 As d20$,10 As d50$,10 As d80$, 5 As dtm$
field #7,325 As z$, 5 As dtd$, 5 As din$, 2 As dpw$,20 As dct$
field #7,357 As z$, 10 As dlm$,24 As dsr$,15 As dar$,10 As dua$
field #7,416 As z$, 1 As dcx$,10 As dob$, 3 As dlv$, 4 As dqn$
field #7,434 As z$, 5 As dkm$, 4 As dsd$, 3 As dxx$, 4 As dun$
All logic aside for the moment, this has been running for about seven
years (ALL files being opened in this fashion) at a number of user
sites. What problems there were, were very rarely disk file related,
and by far the most were simply due to the odd condition not catered
for.
Now, in response to a user enquiry (they had encountered file
corruption in a known set of circumstances), I have tried to use:
To only READ, and permit other workstations to also read, but not
write --
Open kdd$+(filename) Access READ Lock WRITE As #x
To read AND write, as when file maintenance is performed, and permit
other users NO access to the record --
Open kdd$+(filename) Access READ WRITE Lock READ WRITE As #x
In all cases only RECORDS are locked before access and immediately
afterwards unlocked, except in the case of "maintenance" (read/write).
The file is closed as well, except in the "read write" case, where
this is not done until the record has been refiled and unlocked.
Only the two modules in question were modified in this way and sent
to the user site, with interesting results. Now, when two workstations
both use the "read" only (no write) module, and one of these selects
an account from the menu AND accesses that account and stays there,
then, when the second station tries to select one likewise (a different
record), an error 70 (access denied) occurs, and it keeps on retrying,
using RESUME. The moment the first station exits its record and returns
to the menu, the second user immediately gains access. All this when
only RECORD locking is used, as in --
da%=dr%(sb%+op%-1)
Lock #7,da%
Get #7,da%
UnLock #7,da%
Is there a hole in the logic, or is it twisted logic? The PB examples
do describe these things, but then proceeds to give examples with no
file or record locking illustrations.
What is the correct way in the various combinations of Access READ
and/or WRITE and Lock READ and/or WRITE situations? There are random,
binary and a few sequential files involved. The binary files are locked
"from/to byte". In the case of sequential files the whole file is
locked.
<< "the article explicitly states that applications that may access a file from multiple PC's at the "same instant" should must definately use locking to ensure local file caching does not lead to data loss." >>
Comment