5,838
edits
m (→Releases 3.0.0 to 3.11.4 inclusive: add links) |
mNo edit summary |
||
Line 7: | Line 7: | ||
This file holds a SQLite3 database. | This file holds a SQLite3 database. | ||
There are many software tools available that can read/edit SQLite3, this is not the place to get too technical, but take a look at '''sqlitebrowser''' in a Linux environment, and '''phpLiteAdmin''' in Microsoft Windows. Also, you could use any application that can read ODBC files (e.g. Libre Office's Base functionality), these can read the MX databases. | |||
=Releases 3.0.0 to 3.11.4 inclusive= | =Releases 3.0.0 to 3.11.4 inclusive= | ||
The database only contains one table '''StandardData'''. | The database only contains one table '''StandardData'''. In [https://cumulus.hosiene.co.uk/viewtopic.php?p=123594#p123594 this forum post] Steve Loft describes this table as being for a possible future enhancement. It is believed this is the table that Steve had developed in Cumulus 2, as a replacement for the [[Monthly_log_files]]. In [https://cumulus.hosiene.co.uk/viewtopic.php?p=113475#p113475 another forum post] he does give a little more detail about his proposal for Cumulus 3 (MX), and this is backed up by his choice of [[Standard log files|table name]] which suggests he was planning to either replace, or duplicate, the use of text files for logging data. It appears he was actually thinking about implementing [[Monthly_log_files#Enhancement never implemented]] from his inclusion of "Lo" and "Hi" values in the column list. Despite the evidence supporting that idea, it is a possible alternative that Steve Loft actually thought he could improve on the [[Recent history]] functionality, by storing the highest and lowest readings read from weather station in-between the one minute resolution. Whatever context it was to have been implemented in, its purpose was to improve the ability to [[Correcting Extremes|Correct Extremes Records]] by storing the most frequent and accurate extremes possible. | ||
Here is the relevant create table instruction, so this tells you the 17 fields in the | Here is the relevant create table instruction, so this tells you the 17 fields in the table as Steve created it (these have never been changed): | ||
CREATE TABLE "StandardData"( | CREATE TABLE "StandardData"( | ||
"Timestamp" datetime primary key not null , | "Timestamp" datetime primary key not null , | ||
Line 34: | Line 35: | ||
Whenever I have viewed this table (with phpLiteAdmin), there has been zero rows within the table. This is because although MX creates the table, currently it does not actually use it. | Whenever I have viewed this table (with phpLiteAdmin), there has been zero rows within the table. This is because although MX creates the table, currently it does not actually use it. | ||
This table still exists in release 3.12.0 that introduces the second table described below | This table still exists in release 3.12.0 that introduces the second table described below. | ||
=Release 3.12.0 onwards= | =Release 3.12.0 onwards= | ||
Release 3.12.0 introduces a second table '''RecentData''' into the same database. This is documented in the update.txt for CumulusMX at release 3.12.0 (beta build 3134) as "Change: Cumulus MX now uses a persistent database to store the recent 1 minute data | The first table, described above, remains in the database, but is still not being used. I wonder whether MX in the future will actually implement the intended use of this first table, as described above. | ||
- This means that charts, recent | |||
Release 3.12.0 introduces a second table [[Recent history|'''RecentData''']] into the same database. This is documented in the update.txt for CumulusMX at release 3.12.0 (beta build 3134) as "Change: Cumulus MX now uses a persistent database to store the recent 1 minute data | |||
- This means that charts, recent web tags, and internal calculations for trends and periodic values will be more accurate after a restart | |||
- If Cumulus MX is offline for a prolonged period, data for that offline period will obviously still be at the station logging interval resolution". | - If Cumulus MX is offline for a prolonged period, data for that offline period will obviously still be at the station logging interval resolution". | ||
This second table has the following columns: | This second table has the following columns: |
edits