Hi Viktor,
IMO, it is a bug in Clipper - It should throw a runtime error - IOW,
the app thinks it wrote data but the data was never written (ie. was
lost) and therefore, that's a bug!
I see no practical reason why someone would want to do this AND I
can see that a developer would want to know that it is happening.
The problem is that some existing code can break if we
change this.
We cannot be exactly sure why the Clipper team has chosen
this way of working (maybe to maintain compatibility with
dBase), but it was surely intentional. It also seems consistent
that reads of fields when on EOF also don't return a RTE.
Moreover RLOCK() also returns .T. when on EOF (this is even
documented in the NG), which suggest that EOF is consistently
handled in a silent, "optimistic", "friendly" way all along
Clipper.
"Normal" app code should check for this condition IMO, before
writing to a record.
We could classify this a bug, if any of the CA shipped RDDs
would handle this matter inconsistently. (say DBFCDX in 5.3
would RTE).
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
