Year after year, feature after feature, the diagnostic log has grown into a massive file on busy servers. With 4D v19R5, we included a new database parameter allowing you to choose the log level of the diagnostic log file. It will help you control the diagnostic log size by logging only what you really need.
For 4D v19, we started a long-term refinement of our logs. Our first effort was to improve their format to give you better and clearer information. As for 4D v19 R3, we added 2 new functionalities: the ability to instantly pause logging and a way for support teams to easily help their customers configure their logs through a configuration file.
By now, you’ve surely discovered the new ability to identify your users thanks to the SET USER ALIAS command. In 4D v18 R2, the command’s behavior has been extended. How? Keep reading!
Ever need to analyze the traffic of your ORDA requests between a client and the 4D server? Sometimes it may take a while to receive a response from the server, which can make you wonder if it’s due to network traffic or to an unoptimized request you’ve written! Thankfully, 4D v17 R6 makes it possible to determine the likely reason(s) for this latency with the new ORDA methods available on the ds object. They’re not only debugging functions, they also allow you to optimize your ORDA code with a better understanding of the sent requests.
With 4D v17 R5, we’ve improved the debug logs by adding methods and allowing each process to be traced independently. With this R-release, we’ve gone a step further by shipping a debug logs analyzer tool to help you monitor process execution. You’ll be able to see which processes are the most consuming, the call chain with the corresponding running time, and much more.
As a 4D developer, you may have already activated the debug log to troubleshoot problems. 4D v17 R5 introduces several improvements to help you analyze these files, such as logging only the current process and logging calls to member methods (collection or object methods).
As promised in a previous post, each R-release includes more advances related to email functionality, unlocking its hidden power.
4D v17 R5 provides an interesting new feature for email logs. Sometimes during development everything works fine but when you deploy to the customer, there’s a problem delivering emails. Discovering where the failure occurs can be difficult, since the communication is encrypted and you often don’t have access to the SMTP server log files. The problem is very likely related to your SMTP server, but how can you be sure? Simply start the SMTP log in your application! This log contains a record of all the actions performed, including those stopping the connection. Even better, this log shows the communications with the SMTP server in plain, non-encrypted text, making it easier to analyze.
Log files can be extremely useful for troubleshooting. They’re also a big help for finding the root cause of an incident. Logs let us track of where a problem occurred, and when. Before, with the Get 4D folder command, you could easily access the folder containing all the logs. Now, 4D v16 R6 makes easy to find a particular log file, thanks to the enhancement of the Get 4D file command.