Cumulusmx.db (preserving history) - Revision history

HansR: HansR moved page Cumulusmx.db to Cumulusmx.db (preserving history) without leaving a redirect: Rewrite of contents

2022-10-01T09:09:52Z

HansR moved page Cumulusmx.db to Cumulusmx.db (preserving history) without leaving a redirect: Rewrite of contents

← Older revision

Revision as of 09:09, 1 October 2022

Sfws: Further minor layout change

2022-09-05T05:19:22Z

Further minor layout change

← Older revision		Revision as of 05:19, 5 September 2022
Line 7:		Line 7:
	==Location of this database file==		==Location of this database file==

	* This database file is specific to Cumulus MX (as the file name suggests), not used by legacy Cumulus 1		* This database file/files is/are specific to Cumulus MX (as the file name suggests), not used by legacy Cumulus 1
	* ~~The file is held in Random Access Memory in~~ MX Releases 3.0.0 to 3.11.4 inclusive		* For MX Releases 3.0.0 to 3.11.4 inclusive, there were two databases with this name:
			*# One database table with this name was held in Random Access Memory for MX Releases 3.0.0 to 3.11.4 inclusive
	* ~~This~~ database ~~file~~ is stored as '''/CumulusMX/data/cumulusmx.db''' (get case of each character correct unless Microsoft Windows Operating System~~) from release 3.12.0 (beta build 3134~~)		*# One database table with this name is stored as '''CumulusMX/data/cumulusmx.db''' (get case of each character correct unless Microsoft Windows Operating System)
			* The two database tables were merged from release 3.12.0 (beta build 3134) and stored as '''/CumulusMX/data/cumulusmx.db''' (get case of each character correct unless Microsoft Windows Operating System)

	==Database type==		==Database type==

	This file holds a SQLite3 database. Databases of this type are based on sequential file design, i.e. each row in the database table is sequenced by when created (new rows are only appended on end), and given a sequential number to act as primary key (numbers are not automatically revised when a row is deleted).		This file/files holds a SQLite3 database. Databases of this type are based on sequential file design, i.e. each row in the database table is sequenced by when created (new rows are only appended on end), and given a sequential number to act as primary key (numbers are not automatically revised when a row is deleted).

	The MX [[Weather Diary]] also uses a SQLite3 database stored in [[diary.db]].		The MX [[Weather Diary]] also uses a SQLite3 database stored in [[diary.db\|CumulusMX/data/diary.db]].

	== Reading/editing database table outside MX ==		== Reading/editing database table outside MX ==
Line 44:		Line 46:
	\| RecentData		\| RecentData
	\| Updated once a minute when MX is running		\| Updated once a minute when MX is running
		⚫	\| MX beta 3.0.0
	\| Changed:
			* Database of this name with this table originally in RAM
⚫	* MX beta 3.0.0 ~~in RAM~~
	* 3.12.0 (beta build 3134) as external file		* In 3.12.0 (beta build 3134) table moved to external file
	\| The update.txt for CumulusMX at release 3.12.0 (beta build 3134) states "Change: Cumulus MX now uses a persistent database to store the recent 1 minute data		\| The update.txt for CumulusMX at release 3.12.0 (beta build 3134) states "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		- This means that charts, recent web tags, and internal calculations for trends and periodic values will be more accurate after a restart
Line 56:		Line 58:
	\| Updated when certain conditions are met and SQL is queued		\| Updated when certain conditions are met and SQL is queued
	\| MX 3.21.0		\| MX 3.21.0
	\| The update.txt for CumulusMX at release 3.21.0 states "New		\| The update.txt for CumulusMX at release 3.21.0 states "New - Failed MySQL commands can now be individually edited/deleted
	- Failed MySQL commands are now can now be individually edited/deleted

		⚫	Changed - Failed MySQL commands are now stored in the SQLite database to persist across Cumulus runs"
	Changed
⚫	- Failed MySQL commands are now stored in the SQLite database to persist across Cumulus runs"

	\| Edit or purge the failed MySQL command queue using '''Utils menu''' -->> ''PurgeMySQL''		\| Edit or purge the failed MySQL command queue using '''Utils menu''' -->> ''PurgeMySQL''
Line 68:		Line 68:
	\| At time of writing, the current MX release does not use this table		\| At time of writing, the current MX release does not use this table
	\| MX beta 3.0.0		\| MX beta 3.0.0
			(always in file)
	\| 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=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]].
	\| At time of writing, the current MX release does not use this table		\| At time of writing, the current MX release does not use this table

Sfws: layout

2022-09-05T04:48:55Z

layout

← Older revision		Revision as of 04:48, 5 September 2022
Line 44:		Line 44:
	\| RecentData		\| RecentData
	\| Updated once a minute when MX is running		\| Updated once a minute when MX is running
			\| Changed:
	\| * MX beta 3.0.0 in RAM		* MX beta 3.0.0 in RAM
	* 3.12.0 (beta build 3134) as external file		* 3.12.0 (beta build 3134) as external file
	\| The update.txt for CumulusMX at release 3.12.0 (beta build 3134) states "Change: Cumulus MX now uses a persistent database to store the recent 1 minute data		\| The update.txt for CumulusMX at release 3.12.0 (beta build 3134) states "Change: Cumulus MX now uses a persistent database to store the recent 1 minute data

Sfws: typo

2022-09-05T04:46:24Z

typo

← Older revision		Revision as of 04:46, 5 September 2022
Line 15:		Line 15:
	This file holds a SQLite3 database. Databases of this type are based on sequential file design, i.e. each row in the database table is sequenced by when created (new rows are only appended on end), and given a sequential number to act as primary key (numbers are not automatically revised when a row is deleted).		This file holds a SQLite3 database. Databases of this type are based on sequential file design, i.e. each row in the database table is sequenced by when created (new rows are only appended on end), and given a sequential number to act as primary key (numbers are not automatically revised when a row is deleted).

	The MX [[~~weather~~ ~~diary~~]] also uses a SQLite3 database stored in [[diary.db]].		The MX [[Weather Diary]] also uses a SQLite3 database stored in [[diary.db]].

	== Reading/editing database table outside MX ==		== Reading/editing database table outside MX ==

Sfws: Rewritten for MX release 3.21.0

2022-09-05T04:45:14Z

Rewritten for MX release 3.21.0

Show changes

Sfws at 16:11, 16 June 2022

2022-06-16T16:11:30Z

← Older revision		Revision as of 16:11, 16 June 2022
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'''. 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.
	The database only contains one table '''StandardData'''.

	Here is the relevant create table instruction, so this tells you the 17 fields in the ~~file~~:		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.

⚫	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. In [https://cumulus.hosiene.co.uk/viewtopic.php?p=113475#p113475 another forum post] he does give a little more detail about his proposal and this is backed up by his choice of ~~table~~ ~~name. The~~ table name suggests he was planning to duplicate the ~~[[Standard~~ ~~log files\|Standard log~~ text files]] ~~with~~ a ~~database equivalent~~. I ~~suspect~~ he was actually thinking about implementing [[Monthly_log_files#Enhancement never implemented]] from his inclusion of "lo" and "Hi" values in the column list.

	This table still exists in release 3.12.0 that introduces the second table described below. ~~I wonder whether MX in the future will actually implement the intended use of this first table.~~		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=

			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.
⚫	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

⚫	- This means that charts, recent ~~webtags~~, and internal calculations for trends and periodic values will be more accurate after a restart
		⚫	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:

Sfws: /* Releases 3.0.0 to 3.11.4 inclusive */ add links

2021-08-01T10:04:16Z

Releases 3.0.0 to 3.11.4 inclusive: add links

← Older revision		Revision as of 10:04, 1 August 2021
Line 34:		Line 34:
	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.

	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. He ~~gives~~ no ~~clue~~ as to ~~why~~ he ~~selected~~ ~~the~~ ~~above~~ ~~columns~~ or ~~what~~ he ~~was~~ ~~thinking~~ ~~about~~ ~~using~~ ~~them~~ ~~for.~~ The table name suggests he was planning to ~~replace~~ the [[Standard log files\|Standard log text files]] with a database equivalent. I suspect he was actually thinking about implementing [[Monthly_log_files#Enhancement never implemented]].		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. In [https://cumulus.hosiene.co.uk/viewtopic.php?p=113475#p113475 another forum post] he does give a little more detail about his proposal and this is backed up by his choice of table name. The table name suggests he was planning to duplicate the [[Standard log files\|Standard log text files]] with a database equivalent. I suspect he was actually thinking about implementing [[Monthly_log_files#Enhancement never implemented]] from his inclusion of "lo" and "Hi" values in the column list.

	This table still exists in release 3.12.0 that introduces the second table described below. I wonder whether MX in the future will actually implement use of this first table.		This table still exists in release 3.12.0 that introduces the second table described below. I wonder whether MX in the future will actually implement the intended use of this first table.

	=Release 3.12.0 onwards=		=Release 3.12.0 onwards=

Sfws: /* Releases 3.0.0 to 3.11.4 inclusive */

2021-08-01T08:56:26Z

Releases 3.0.0 to 3.11.4 inclusive

← Older revision		Revision as of 08:56, 1 August 2021
Line 32:		Line 32:
	"HiPressure" float )		"HiPressure" float )

	Whenever I have viewed this table (with phpLiteAdmin), there has been zero rows within the table.		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.

	~~Unless~~ ~~anyone~~ ~~else~~ ~~knows~~ ~~differently,~~ I ~~believe~~ this table ~~was~~ ~~created~~ by ~~Steve~~ ~~Loft~~ ~~because~~ he ~~was~~ ~~unsure~~ ~~whether~~ to ~~use~~ ~~text~~ ~~files~~ or ~~database~~ ~~files~~ in ~~Cumulus~~ 2 ~~and 3. Someone~~ ~~suggested~~ he ~~used~~ ~~SQLite3~~ ~~database~~ ~~tables,~~ ~~and~~ I ~~believe~~ ~~this~~ table ~~represents~~ ~~Steve~~ ~~Loft's~~ ~~attempt~~ to replace the [[Standard log files\|Standard log text files]] with a database equivalent.		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. He gives no clue as to why he selected the above columns or what he was thinking about using them for. The table name suggests he was planning to replace the [[Standard log files\|Standard log text files]] with a database equivalent. I suspect he was actually thinking about implementing [[Monthly_log_files#Enhancement never implemented]].

			This table still exists in release 3.12.0 that introduces the second table described below. I wonder whether MX in the future will actually implement use of this first table.
	I also assume that when Mark Crossley took over MX development, he found this database table in the package Steve Loft left, and not then understanding how the code worked, he kept this table and kept the code (one reference is in module [[Cs_Code_Modules#Cumulus.cs\|Cumulus.cs]]) that created the database and this table.

	=Release 3.12.0 onwards=		=Release 3.12.0 onwards=

Sfws: /* Releases 3.0.0 to 3.11.4 inclusive */

2021-07-31T21:28:39Z

Releases 3.0.0 to 3.11.4 inclusive

← Older revision		Revision as of 21:28, 31 July 2021
Line 34:		Line 34:
	Whenever I have viewed this table (with phpLiteAdmin), there has been zero rows within the table.		Whenever I have viewed this table (with phpLiteAdmin), there has been zero rows within the table.

			Unless anyone else knows differently, I believe this table was created by Steve Loft because he was unsure whether to use text files or database files in Cumulus 2 and 3. Someone suggested he used SQLite3 database tables, and I believe this table represents Steve Loft's attempt to replace the [[Standard log files\|Standard log text files]] with a database equivalent.

			I also assume that when Mark Crossley took over MX development, he found this database table in the package Steve Loft left, and not then understanding how the code worked, he kept this table and kept the code (one reference is in module [[Cs_Code_Modules#Cumulus.cs\|Cumulus.cs]]) that created the database and this table.
	It is not documented anywhere I have seen what option you have to turn on in MX to start this database being updated. The file is created when you run MX, it is not included in the release distribution to ensure any data you have in the database table is kept when you install a new MX version.

	<big>Could anyone who knows what option in MX updates this file, and in what context use is made of this database table, please explain it by amending this section</big>

	=Release 3.12.0 onwards=		=Release 3.12.0 onwards=

Sfws: /* Release 3.12.0 onwards */ typo

2021-07-31T21:04:17Z

Release 3.12.0 onwards: typo

← Older revision		Revision as of 21:04, 31 July 2021
Line 51:		Line 51:
	! style="width:80px" \| Column name		! style="width:80px" \| Column name
	! style="width:80px" \| Column type		! style="width:80px" \| Column type
	! style="width:~~180px~~" \| Properties		! style="width:280px" \| Properties
	! style="width:450px" \| Description		! style="width:450px" \| Description
	! style="width:120px" \| Example column value		! style="width:120px" \| Example column value

← Older revision		Revision as of 21:04, 31 July 2021
Line 51:		Line 51:
	! style="width:80px" \| Column name		! style="width:80px" \| Column name
	! style="width:80px" \| Column type		! style="width:80px" \| Column type
	! style="width:~~180px~~" \| Properties		! style="width:280px" \| Properties
	! style="width:450px" \| Description		! style="width:450px" \| Description
	! style="width:120px" \| Example column value		! style="width:120px" \| Example column value