Par2: EOF() - discussion of proper utilization 1998-05-18 -- Sean Wilson Back in the good ol' days of DOS, when single user databases were the norm, the
EOF() (and the BOF()) function provides a convenient means of terminating a loop
for processing a file, e.g:
LOOP UNTIL EOF()
NEXT(f)
...
END
As multi-user systems took over, the use of the EOF() function became problematic. In
a nutshell, it is possible for EOF() to return FALSE and yet have the NEXT() file read
fail
as a result of reading past the end of the file. This can happen when a second station
deletes the last record in a file in the time between the first stations calls to EOF()
and
NEXT().
This isn't the only problem though. In the not too distant past, the behaviour of all the
Clarion File Drivers was standardised by converting to use the File Driver Kit. The File
Driver Kit attempts to ensure that all supported functions behave identically accross
all File Drivers. At this point it was clear that the only safe way to test for an
end-of-file
condition was to test the result of the NEXT() function, e.g:
LOOP
NEXT(f)
IF ERRORCODE() THEN
BREAK
END
...
END
The closely related NEXT(), PREVIOUS(), EOF() and BOF() functions are generally
implemented for best performance in this kind of scenario since efficient multi-user
operation is required. Furthermore, for reliability each of these functions must attempt
a record fetch in order to be sure that a record is available for processing (in pre-CW
drivers, EOF() might return the value of a flag). This means that loops patterned after
our first example can actually take twice as long to process (and possibly more) than
the second example.
So as a general rule of thumb, never use EOF() or BOF() to control a loop. In fact, if
possible avoid the use of EOF() and BOF() altogether.
Printed November 23, 2024, 10:19 pm This article has been viewed/printed 35211 times. |