4D uses a journal/log file system to record actions performed to the data as a backup redundancy feature. Should the datafile get corrupted, or somehow the data was not committed to the datafile, the logs can be used to integrate the data back into the datafile up until the latest action saved in the logs.

With this system there are two modes, Strict mode and Auto repair mode.

With Strict mode, if any action does not make sense, an error is reported and the integration fails. An example would be a Modify event on a record, however the record does not exist.

With Auto repair mode, the system will look at the any actions that does not make sense and perform an action that will arrive at the same result. With the prior example, the system knows that the end result will have a record with the final values after the Modify, so it will simply Create the record with the final values.

Both the systems have their pros and cons.
If there are issues in Strict mode, there will be awareness that there are incosistencies with the datafile state compared to what the logs expect, however, it will not be possible to recover a datafile with up to date data.

If there are issues in Auto repair mode, a datafile can be recovered regardless of inconsistencies. On the negative side, one can not be sure if there are any other inconsistencies that were not caught. If one record that should be in the data does not exist, there is a possibility that there are other missing records.

It is important to be aware of these differences and make a pratical choice when deciding on which mode to use. Strict mode can be used until it fails, and if a datafile is needed Auto repair mode can be used with the knowledge that there are some inconsistencies. Strict mode can then be reenabled, and if more inconsistencies appear in the future that can be investigated.