There was a previous thread about this message w/ SQL in which the difficulty of tracking the cause was noted. Having again faced the problem recently, I revisited the situation in an attempt to come up with a debug option to help.
By adding a #pragma and code in the FileManager.EqualBuffer method, I can now easily see the first byte in the file record that appears as having been changed. However, w/ some tables, it can still be difficult to know the exact record field to which the changed byte corresponds.
For instance, if the debug code shows CHR(32) vs CHR(0) at byte 832 in the Clarion record buffer, is there an easy way to determine the relevant field name (other than manually adding up all the field sizes)? My recent tests using various combinations of WHO, WHERE have not been successful.