On 2022-09-23 19:57, Stefan Ram wrote:
I wrote a small Python script to append a line to the end
of a log file. This script is invoked from a VBA subroutine
to append a line to that log file.
In the same VBA subroutine, I then read the last line from
the same log file and compare it with the line to be written.
If they do not agree, the VBA subroutine opens a new message
box informing the user.
That is an awful idea IMO. With disastrous performance as it would block
the logging file for a long time.
The key point is that logging is secondary to functionality. Thus
whatever might happen with the logs, that shall not disrupt normal
operation.
For example, in a real-time application logger queues messages instead
of writing them. Then a lower priority task flushes the log messages
queue to the disk in background.
This might sound overly defensive, but in fact it is not
infrequent that I happen to see that dialog! Reasons might include
problems with the character encoding, full disks, or recently,
a possible spurious error message for reasons (yet) unknown
(maybe due to an overload of the system, which led to timeouts).
You should simply flush the log file periodically (keeping it open of
course).
Modern file systems do caching, mirroring, journaling, "never-overwrite-same-block" stuff. You cannot do any better from a VBA application! You even cannot know if the stuff you read back was
actually physically written down to the physical medium and not sitting
in some N-th order cache of some M-th controller in between... (Mission critical logger solutions like blackboxes may use special hardware
write-once mediums etc)
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)