Dayfile.txt: Difference between revisions

You might also, as I did, want your script to validate what it reads from the daily summary log to ensure only valid numbers and times are stored in your database table, while any invalid inputs are stored as nulls by your script. In my own case, my daily summary table has no solar columns but it does have several additional columns (including the daily increment of chill hours, the cumulative chill hours, the contents of the Weather Diary, the time of the last rain tip, wind bearings as compass characters (e.g. NNW) as well as numerical bearings). When I used Cumulus 1 I wrote a PHP script to find all these additional values, for example it reads the [[today.ini]] and [[month.ini]] log files as stored in the end of day backup (not the ones being updated for new day in data folder), butand otherthe sources[[log.xml|weather arediary in log.xml in alsodata usedfolder]].

MX allows you to specify a different schema in the SQL it generates, but it does not offer that validation feature I just mentioned. I continue to use my Cumulus 1 script (with some changes as for example the weather diary works differently, I am querying SQLite from \CumulusMX\data\diary.db) now I use MX. In the MX standard functionality, you are limited to using web tags for your inputs, and some of those are affected by the end of day process. I tried various content in the custom EOD query, but it did not give me what I need for the scripts that produce my web pages.

MX automatically stores all end of month figures as log files, a feature that Cumulus 1 and 2 lacked, but as yet it does not actually use this extra data, and provides no simple facility to put what is in these files into database tables. There is no end-of-month selection for updates in MX, so you can't easily get as much from dayfile.txtxt as I do.