ladb.log not being written to

I'm not sure you have a problem.  We're are also Windows, running 9.0.1.5, and I do a weekly reboot which includes a script to archive off and delete the ladb, latm and lajs logs.  It's not uncommon to go an entire week without records written to the ladb and latm logs except for the startup and shutdown entries.  If there are error conditions encountered though, those records do get written out as they occur.

have you tried to force an error condition to see if anything goes to ladb.log?  (like putting an invalid password in your MICROSOFT file...on a test prodln of course).

We are on Unix and we can go several days/weeks without anything being written to the ladb.log file except for when we shutdown and restart for backups. When there are errors they are being written to it.

Thanks for the responses. This is only happening on live and no errors have been written since 9/25. I'd like to be able to force an error if there was something somewhat non-invasive that I could do on the live system. What types of things would force an error that would not be a big deal to do on live?

From the errors I see in my ladb logs, they are all big deals -- unable to connect to the db server, bad triggers to my frontoffice TM app, etc. I'm not aware of any trivial conditions that would write out to that log. The fact that you get the startup/shutdown entries in the log tells me that the system is able to write to the file successfully.

If I really had to prove this out, I might consider doing a quickpaint on an empty table in an unused system code (it would be SL for me), drop the table with bldxxxddl, try to access the table which should generate the error, then rebuild the table. It's not totally non-invasive or risk-free...but that's all I could think of.

if you have another prodline in the same environment like test etc. You can take the test database offline and force some ladb.log entries. Or you can put it in read only mode and attempt to change data. That should do it.