A new system variable is available to get the offending 4D code that generates an error. With 4D v15 R4 whenever an error is raised you have a means to get the offending code in addition to getting the error code, as well as the method and line where the error occurred.
The METHOD GET CODE command has been enhanced to export the method code and get the very same result whatever the name of the commands, tables, fields, and regardless of the programming language of the 4D product used…
To do so the tokens of the code elements (4D commands, 4D constants, tables, fields, etc.) are exported with them. These tokens are unique and can be interpreted as the elements they represent by 4D even if their names have been upgraded or if they are written in another language than that of the 4D that executes it.
When integrating the log file, 4D stops at the first error and doesn’t return any error message. Reasons for integration errors could be a damaged log, by example because of a bad hard disk or software error during writing. If that error happens at the end, no problem; but it could also be at the start or in the middle of the log. In this case, the data after the error might be useful.
Now, when the integration fails in standard mode, you can try integration in auto-repair mode. In this case, 4D tries to resolve the error encountered, doesn’t stop the integration, and returns the error list.
In 4D applications, the data file is important, so all the activity of the database is stored in the log file. As you all know, the log file is a vital element for the restoration of your database following an unfortunate contingency. However all the information on the database activity may also be useful for analysis. For example, to check the activity on a table, to see the changes made by a user, and to follow a record’s history.