How the automatic update logic works
Warning! It is important to understand that the framework may not always be able to know how to update when using a package file generated by the DUFCodeGenerator utility. It doesn't really matter if it is an embedded DataFlex or SQL table, the same logic applies.
When a table has been changed the following logical order is performed internally by the framework;
1) New fields are inserted
2) Fields with the same name are moved to their new position
3) Fields are renamed
Example
Consider the following example scenario. The "New Table" is in development and the "Current Table" is at customer site;
# |
New Table |
Data Type |
Length |
# |
Current Table |
Data Type |
Length |
0 |
Recnum |
Numeric |
8,0 |
0 |
Recnum |
Numeric |
8,0 |
1 |
FilterRec |
Numeric |
6,0 |
1 |
FilterRec |
Numeric |
6,0 |
2 |
CreatedDate |
Date |
6,0 |
2 |
CreatedDate |
Date |
6,0 |
3 |
CreatedTime |
ASCII |
5 |
3 |
CreatedTime |
ASCII |
5,0 |
4 |
ReferencePoint |
Numeric |
6,2 |
4 |
ValueOld |
Numeric |
4,2 |
5 |
FilterOld |
Numeric |
6,2 |
5 |
ValueNew |
Numeric |
4,2 |
6 |
FilterNew |
Numeric |
6,2 |
6 |
Type |
ASCII |
1 |
7 |
Capture |
Numeric |
6,2 |
7 |
Div_Deep |
Numeric |
6,2 |
8 |
Type |
ASCII |
1 |
8 |
Div_Color |
Numeric |
6,2 |
9 |
Div_Deep |
Numeric |
6,2 |
9 |
Div_No |
ASCII |
12 |
10 |
Div_Color |
Numeric |
6,2 |
10 |
Labelling |
ASCII |
60 |
11 |
Div_No |
ASCII |
12 |
---- |
---- |
-- |
|
12 |
Labelling |
ASCII |
60 |
---- |
---- |
-- |
|
13 |
BroTableRef |
Numeric |
4 |
---- |
---- |
-- |
What can be deduced fromt he above? (We will assume that no fields has been deleted)
•The first three fields are unchanged.
•Three new fields have been added. However, they two of them have not been added to the end of the table, instead two have been inserted and one added at the end.
•Two fields seems to have changed in length (ValueOld and ValueNew)
•Two fields seems to have been renamed, but we cannot be sure.
NOTE: It is important to remember that - not only when dealing with the embedded database - new fields should always be added at the end of a table. This has been an SQL general guideline for decades.
In the above example, and if no pre-preparation of the table is made, DUF would make a mess of the table.
So what could be done to prepare this table before using the auto-generated packed from the DUFCodeGenerator program?
The truth of the above is that the two new fields; "ReferencePoint", "Capture" have been inserted and a new field "BroTableRef" has been added to the end of the table. The two fields "ValueOld" and "ValueNew" have been renamed and have a new length.
If we would rename "ValueOld" to "FilterOld" and "ValueNew" to "FilterNew" we would be in a much better situation.
Other preparations that might be needed is for example if the filelist.cfg contains an empty file slot. That will generate an error and the DUF conversion will stop. That can be fixed by using the ApiTableRemove function.
If a table has been moved to another place (slot) in the filelist, the ApiTableMoveFileListEntry function can be used to prepare before using the auto-generated package.
Example Solution
Procedure OnUpdate
Object oDbUpdateHandler is a cDbUpdateHandler
Set piDbVersionFileNumber to 200
Set piDbVersionFieldNumber to 1
Set pbAutoCreateDbVersionTable to True // Automatically creates the DbVersion table when the program is started.
Object oDbUpdateVersion0_9 is a cDbUpdateVersion
Set pnVersionNumber to 0.9
// To prepare the database before the auto-generated package is used.
Procedure OnUpdate
Boolean bOK
Handle hTable
Move 178 to hTable
Get ApiTableRemove hTable to bOK // Filelist slot that does not have a file on disk.
// Move table "Location" from filelist slot 6 to 10 etc.
Get ApiTableMoveFileListEntry "Location" "Location" "Locations" 6 10 "DATAFLEX" to bOK
Get ApiTableMoveFileListEntry "LocId" "LocId" "Location - Id" 3 6 "DATAFLEX" to bOK
Get ApiTableMoveFileListEntry "LocSp" "LocSp" "Location - Sp" 4 7 "DATAFLEX" to bOK
Get ApiTableMoveFileListEntry "LocFi" "LocFi" "Location - Filters" 5 8 "DATAFLEX" to bOK
Move 18 to hTable
// This table have new fields inserted and added to, as well as new field names and fields that
// have been moved. We need to rename the fields to not confuse DUF, before we use the auto-generated
// package below.
Get ApiColumnRename hTable "ValueOld" "FilterOld" to bOK
Get ApiColumnRename hTable "ValueNew" "FilterNew" to bOK
End_Procedure
End_Object
Use DUF_MultipleTables1_0.pkg // Auto-generatore package.
End_Object
Note: There are also other table and column functions available that might be applicable for pre-processing of a table before an auto-generated package is used. See the help under API Make Database Changes.