Bugs MX release 3.20.0 build 3199 - changes to MySQL settings (CLEARED 3.21.1 - b3205)
Posted: Fri 02 Sep 2022 11:05 am
Edited SUBJECT on 6 Sept to say BUGS CLEARED
When I swapped from legacy Cumulus to MX I was able to use the Custom SQL at rollover functionality. I had multiple queries with semi-colons in-between typed into the very small input box on the "MySQL Settings" page. There were conditionals included and MX was successfully running the appropriate queries at each end of day totally reliably up to release 3.19.3 build 3196.
Your release announcement for 3.20.0 stated that up to 10 URLs for HTTP calls, and up to 10 SQL specifications for Custom Seconds/Minutes/Rollover processing by MySqlConnect could now be entered. So I put my queries in individual boxes on the MySQL setting screen in 3.20.0, as separating the commands made it easier to see the various conditionals, but otherwise did not change the MySQL settings. My database tables were successfully updated for the week until I installed new release 3.20.1 build 3203 onto my RPi on 29 August.
On further investigation, your build 3199 coded both the 10 URLs for HTTP calls, and the 10 SQL specifications for Custom Seconds/Minutes/Rollover processing by MySqlConnect, to be read from the "HTTP" section of Cumulus.ini, (the SQL specifications should however be read from "MySQL" section of Cumulus.ini). A further bug tests whether "custom minutes SQL" (should be testing "custom rollover SQL") is enabled to determine if the "custom rollover SQL" should be saved to "MySQL" section of Cumulus.ini. Effectively, MX is not actually saving whatever is typed into the 10 "custom rollover SQL" boxes, so this is a warning to others don't lose your inputs as I did.
After I installed 3.20.1, I stopped then restarted the MX service so it picked up new code. Due to supervising tradespeople on some major work here, I did not check my databases during the 5 days. Today, 2 September, I discovered MX has not even tried to run any of my multiple rollover SQL commands for those 5 days because my SQL typed into the settings page no longer exists due to these bugs I had to find my Cumulus.ini for 3.19.3, which fortunately was backed up, to recover my multiple queries with conditionals.
(I wanted to report this before you release 3.21.0 so have not yet investigated exact extent of the work I now need to do to work out what should have been stored on my various database table rows on each of those 5 days when nothing was stored).
When I swapped from legacy Cumulus to MX I was able to use the Custom SQL at rollover functionality. I had multiple queries with semi-colons in-between typed into the very small input box on the "MySQL Settings" page. There were conditionals included and MX was successfully running the appropriate queries at each end of day totally reliably up to release 3.19.3 build 3196.
Your release announcement for 3.20.0 stated that up to 10 URLs for HTTP calls, and up to 10 SQL specifications for Custom Seconds/Minutes/Rollover processing by MySqlConnect could now be entered. So I put my queries in individual boxes on the MySQL setting screen in 3.20.0, as separating the commands made it easier to see the various conditionals, but otherwise did not change the MySQL settings. My database tables were successfully updated for the week until I installed new release 3.20.1 build 3203 onto my RPi on 29 August.
On further investigation, your build 3199 coded both the 10 URLs for HTTP calls, and the 10 SQL specifications for Custom Seconds/Minutes/Rollover processing by MySqlConnect, to be read from the "HTTP" section of Cumulus.ini, (the SQL specifications should however be read from "MySQL" section of Cumulus.ini). A further bug tests whether "custom minutes SQL" (should be testing "custom rollover SQL") is enabled to determine if the "custom rollover SQL" should be saved to "MySQL" section of Cumulus.ini. Effectively, MX is not actually saving whatever is typed into the 10 "custom rollover SQL" boxes, so this is a warning to others don't lose your inputs as I did.
After I installed 3.20.1, I stopped then restarted the MX service so it picked up new code. Due to supervising tradespeople on some major work here, I did not check my databases during the 5 days. Today, 2 September, I discovered MX has not even tried to run any of my multiple rollover SQL commands for those 5 days because my SQL typed into the settings page no longer exists due to these bugs I had to find my Cumulus.ini for 3.19.3, which fortunately was backed up, to recover my multiple queries with conditionals.
(I wanted to report this before you release 3.21.0 so have not yet investigated exact extent of the work I now need to do to work out what should have been stored on my various database table rows on each of those 5 days when nothing was stored).