Recent changes to DBUpgrade

DBUpgrade modified by Tim Schofield

Tim Schofield — Tue, 15 Oct 2024 09:20:28 -0000

--- v11
+++ v12
@@ -104,3 +104,14 @@
 ![](https://github.com/timschofield/images/blob/master/DBUpgrade3.png)

 This screen gives a summary of the updates. If there were any failures, then these are listed on that page.
+
+## Migration
+
+WebERP will first check whether the database has all the updates from the previous system applied to it (ie is it at least 4.15.2). If not then it uses the old update system to bring it up to a 4.15.2 database. Then it will apply any updates since 4.15.2. This will ensure that no updates are missed in the transition.
+
+## Advantages
+
+1. The interface is more polished and professional.
+2. By using PHP files the updates become DBMS independent.
+3. By using PHP files, strings entered into the database can be translated using gettext
+4. Updates for each new feature or bug fix are isolated into one file, and so greater control of updates can be exercised.

DBUpgrade modified by Tim Schofield

Tim Schofield — Tue, 15 Oct 2024 09:20:28 -0000

--- v10
+++ v11
@@ -1,7 +1,7 @@
 # WebERP database upgrade system.

 ## Synopsis
-To improve the database upgrade system, as in this Issue (https://github.com/timschofield/webERP-svn/issues/34). The idea is to provide DBMS indepenxcent update files, with each new feature having it's own self contained file containing it's necessary updates.
+To improve the database upgrade system, as in this Issue (https://github.com/timschofield/webERP-svn/issues/34). The idea is to apply DBMS independent update files to the webERP database, with each new feature having it's own self contained file containing it's necessary updates.

 ## Files
 Each DBMS will have it's own file containing functions to do each of the necessary database updates. These files will be named includes/UpgradeDB_XXX.php where XXX is the DBMS, as is currently the case with the ConnectDB_XXX.php scripts.
@@ -77,20 +77,20 @@

 `function OutputResult($Msg, $Status) {}`

-More functions can be added if they become needed. Each function carries out some tests on the existing database before applying the update to ensure the users database does not get corrupted by the update.
+More functions can be added as they become needed. Each function carries out some tests on the existing database before applying the update to ensure the users database does not get corrupted by the update.

 The individual update files will be given sequential numbers, starting at 0.php and incrementing by one for each new file. They will be stored in their own directory - sql/updates/ - and they will be the only type of file allowed in this directory. They will take the form:

 ``

-The latest file number that has been processed is stored in the config table under the name "DBUpdateNumber". This is updated by the UpdateDBNo() function, which must always be the last code in the numbered update files.
+The latest file number that has been processed is stored in the config table under the name "DBUpdateNumber". This is updated by the UpdateDBNo() function, which must always be the last code in the numbered update files. THe second parameter to the UpdateDBNo() function is a small description of the updates being done.

 The update files are processed by the Z_UgradeDatabase.php script. When a user with system administrator permissions next logs in, a check is made as to whether there are any updates in the sql/updates folder that have not been applied. If there are, then the following screen is shown:
 ![](https://github.com/timschofield/images/blob/master/DBUpgrade1.png)
@@ -99,7 +99,7 @@

 ![Toggle updates](https://github.com/timschofield/images/blob/be71326884593fd226ced7cc83841cf190466689/DBUpgrade2.png?raw=true)

-To process the updates, the user has to just click on the button. Once thge updates are completed they will be redirected to the following screen
+To process the updates, the user has to just click on the button. Once the updates are completed they will be redirected to the following screen

 ![](https://github.com/timschofield/images/blob/master/DBUpgrade3.png)

DBUpgrade modified by Tim Schofield

Tim Schofield — Tue, 15 Oct 2024 09:20:28 -0000

--- v9
+++ v10
@@ -102,3 +102,5 @@
 To process the updates, the user has to just click on the button. Once thge updates are completed they will be redirected to the following screen

 ![](https://github.com/timschofield/images/blob/master/DBUpgrade3.png)
+
+This screen gives a summary of the updates. If there were any failures, then these are listed on that page.

DBUpgrade modified by Tim Schofield

Tim Schofield — Tue, 15 Oct 2024 09:20:28 -0000

--- v8
+++ v9
@@ -98,3 +98,7 @@
 This screen lists all the available update files that have not been applied. Clicking on the arrow by the side of the update file name toggles a view of all the updates within that file:

 ![Toggle updates](https://github.com/timschofield/images/blob/be71326884593fd226ced7cc83841cf190466689/DBUpgrade2.png?raw=true)
+
+To process the updates, the user has to just click on the button. Once thge updates are completed they will be redirected to the following screen
+
+![](https://github.com/timschofield/images/blob/master/DBUpgrade3.png)

DBUpgrade modified by Tim Schofield

Tim Schofield — Tue, 15 Oct 2024 09:20:28 -0000

--- v7
+++ v8
@@ -94,5 +94,7 @@

 The update files are processed by the Z_UgradeDatabase.php script. When a user with system administrator permissions next logs in, a check is made as to whether there are any updates in the sql/updates folder that have not been applied. If there are, then the following screen is shown:
 ![](https://github.com/timschofield/images/blob/master/DBUpgrade1.png)
-THis screen lists all the available update files that have not been applied. Clicking on the arrow by the side of the update file name toggles a view of all the updates within that file:
-![](https://github.com/timschofield/images/blob/master/DBUpgrade2.png)
+
+This screen lists all the available update files that have not been applied. Clicking on the arrow by the side of the update file name toggles a view of all the updates within that file:
+
+![Toggle updates](https://github.com/timschofield/images/blob/be71326884593fd226ced7cc83841cf190466689/DBUpgrade2.png?raw=true)

DBUpgrade modified by Tim Schofield

Tim Schofield — Tue, 15 Oct 2024 09:20:28 -0000

--- v6
+++ v7
@@ -94,3 +94,5 @@

 The update files are processed by the Z_UgradeDatabase.php script. When a user with system administrator permissions next logs in, a check is made as to whether there are any updates in the sql/updates folder that have not been applied. If there are, then the following screen is shown:
 ![](https://github.com/timschofield/images/blob/master/DBUpgrade1.png)
+THis screen lists all the available update files that have not been applied. Clicking on the arrow by the side of the update file name toggles a view of all the updates within that file:
+![](https://github.com/timschofield/images/blob/master/DBUpgrade2.png)

DBUpgrade modified by Tim Schofield

Tim Schofield — Tue, 15 Oct 2024 09:20:28 -0000

--- v5
+++ v6
@@ -93,4 +93,4 @@
 The latest file number that has been processed is stored in the config table under the name "DBUpdateNumber". This is updated by the UpdateDBNo() function, which must always be the last code in the numbered update files.

 The update files are processed by the Z_UgradeDatabase.php script. When a user with system administrator permissions next logs in, a check is made as to whether there are any updates in the sql/updates folder that have not been applied. If there are, then the following screen is shown:
-![](https://photos.google.com/share/AF1QipNB8gUeIaTe-fqvimDyrJW9pxO4IQa53uqEQY-EQ5hFWgpVvzCTGuUYF-5j--RdvQ/photo/AF1QipOi2nAfOVF3T6b8iiTT0hX9wxPtjnq_E4q4S8Ss?key=YVVfV3otWWNFeUpxRGwzMlBnalp0UEVDMkF0V3p3)
+![](https://github.com/timschofield/images/blob/master/DBUpgrade1.png)

DBUpgrade modified by Tim Schofield

Tim Schofield — Tue, 15 Oct 2024 09:20:27 -0000

--- v4
+++ v5
@@ -92,4 +92,5 @@

 The latest file number that has been processed is stored in the config table under the name "DBUpdateNumber". This is updated by the UpdateDBNo() function, which must always be the last code in the numbered update files.

-The update files are processed by the Z_UgradeDatabase.php script. 
+The update files are processed by the Z_UgradeDatabase.php script. When a user with system administrator permissions next logs in, a check is made as to whether there are any updates in the sql/updates folder that have not been applied. If there are, then the following screen is shown:
+![](https://photos.google.com/share/AF1QipNB8gUeIaTe-fqvimDyrJW9pxO4IQa53uqEQY-EQ5hFWgpVvzCTGuUYF-5j--RdvQ/photo/AF1QipOi2nAfOVF3T6b8iiTT0hX9wxPtjnq_E4q4S8Ss?key=YVVfV3otWWNFeUpxRGwzMlBnalp0UEVDMkF0V3p3)

DBUpgrade modified by Tim Schofield

Tim Schofield — Tue, 15 Oct 2024 09:20:27 -0000

--- v3
+++ v4
@@ -4,8 +4,8 @@
 To improve the database upgrade system, as in this Issue (https://github.com/timschofield/webERP-svn/issues/34). The idea is to provide DBMS indepenxcent update files, with each new feature having it's own self contained file containing it's necessary updates.

 ## Files
-Each DBMS will have it's own file containing functions to do each of the necessary database updates. These file will be named includes/UpgradeDB_XXX.php where XXX is the DBMS, as is currently the case with the ConnectDB_XXX.php scripts.
-The functions needed in each file are as follows:
+Each DBMS will have it's own file containing functions to do each of the necessary database updates. These files will be named includes/UpgradeDB_XXX.php where XXX is the DBMS, as is currently the case with the ConnectDB_XXX.php scripts.
+The functions needed in each file are defined as follows:

 `function CharacterSet($Table) {}`

@@ -78,3 +78,18 @@
 `function OutputResult($Msg, $Status) {}`

 More functions can be added if they become needed. Each function carries out some tests on the existing database before applying the update to ensure the users database does not get corrupted by the update.
+
+The individual update files will be given sequential numbers, starting at 0.php and incrementing by one for each new file. They will be stored in their own directory - sql/updates/ - and they will be the only type of file allowed in this directory. They will take the form:
+
+``
+
+The latest file number that has been processed is stored in the config table under the name "DBUpdateNumber". This is updated by the UpdateDBNo() function, which must always be the last code in the numbered update files.
+
+The update files are processed by the Z_UgradeDatabase.php script.

DBUpgrade modified by Tim Schofield

Tim Schofield — Tue, 15 Oct 2024 09:20:27 -0000

--- v2
+++ v3
@@ -1,3 +1,80 @@
 # WebERP database upgrade system.
+
 ## Synopsis
-To 
+To improve the database upgrade system, as in this Issue (https://github.com/timschofield/webERP-svn/issues/34). The idea is to provide DBMS indepenxcent update files, with each new feature having it's own self contained file containing it's necessary updates.
+
+## Files
+Each DBMS will have it's own file containing functions to do each of the necessary database updates. These file will be named includes/UpgradeDB_XXX.php where XXX is the DBMS, as is currently the case with the ConnectDB_XXX.php scripts.
+The functions needed in each file are as follows:
+
+`function CharacterSet($Table) {}`
+
+`function CreateTrigger($Table, $TriggerName, $Event, $Row, $EventSql) {}`
+
+`function NewSecurityToken($TokenId, $TokenName) {}`
+
+`function NewSysType($TypeID, $TypeDescription) {}`
+
+`function NewScript($ScriptName, $PageSecurity) {}`
+
+`function RemoveScript($ScriptName) {}`
+
+`function NewModule($Link, $Report, $Name, $Sequence) {}`
+
+`function NewMenuItem($Link, $Section, $Caption, $URL, $Sequence) {}`
+
+`function RemoveMenuItem($Link, $Section, $Caption, $URL) {}`
+
+`function AddColumn($Column, $Table, $Type, $Null, $Default, $After) {}`
+
+`function AddIndex($Columns, $Table, $Name) {}`
+
+`function DropIndex($Table, $Name) {}`
+
+`function DropColumn($Column, $Table) {}`
+
+`function ChangeColumnSize($Column, $Table, $Type, $Null, $Default, $Size) {}`
+
+`function ChangeColumnName($OldName, $Table, $Type, $Null, $Default, $NewName, $AutoIncrement = '') {}`
+
+`function ChangeColumnType($Column, $Table, $Type, $Null, $Default) {}`
+
+`function ChangeColumnDefault($Column, $Table, $Type, $Null, $Default) {}`
+
+`function RemoveAutoIncrement($Column, $Table, $Type, $Null, $Default) {}`
+
+`function NewConfigValue($ConfName, $ConfValue) {}`
+
+`function ChangeConfigValue($ConfName, $NewConfigValue) {}`
+
+`function ChangeConfigName($OldConfName, $NewConfName) {}`
+
+`function DeleteConfigValue($ConfName) {}`
+
+`function CreateTable($Table, $SQL) {}`
+
+`function ConstraintExists($Table, $Constraint) {}`
+
+`function DropConstraint($Table, $Constraint) {}`
+
+`function AddConstraint($Table, $Constraint, $Field, $ReferenceTable, $ReferenceField) {}`
+
+`function UpdateField($Table, $Field, $NewValue, $Criteria) {}`
+
+`function DeleteRecords($Table, $Criteria) {}`
+
+`function DropTable($Table, $Field) {}`
+
+`function InsertRecord($Table, $CheckFields, $CheckValues, $Fields, $Values) {}`
+
+`function DropPrimaryKey($Table, $OldKey) {}`
+
+`function AddPrimaryKey($Table, $Fields) {}`
+
+`function RenameTable($OldName, $NewName) {}`
+
+`function SetAutoIncStart($Table, $Field, $StartNumber) {}`
+
+`function OutputResult($Msg, $Status) {}`
+
+More functions can be added if they become needed. Each function carries out some tests on the existing database before applying the update to ensure the users database does not get corrupted by the update.