|
|
Once an Export-It installation has been completed the database and all of the installed platforms [computers] will have an associated “version” which is indicated by a text string like the one in black at the top of the example on the right. Three of the components of a version string are marked as "[optional]" and may, or may not, appear in any particular place. That is because the part identified as the "base version" is the only critical component that will always appear to identify a version of the database or software.
The "base version" is four (4) characters and consists of a letter ("A" in this example) that identifies the database format followed by a dash and then two digits (e.g. "28") which identify the EXDOC “Errata” number that indicates the version of the “export rules” implemented in the application. So this example is for EXDOC “Errata 28” which came into force on 1 April 2009 and the database uses “A” format. The sub-version of "a1" only denotes a minor change or revision to at least one program, but not the database layout, since the initial "A-28" version was distributed.
The version of a software program will always appear in the Titlebar of its main window. For example, the RFPs window Titlebar for the example at the right would contain "RFP Processing vA-28a1". For the ExportIt window (where EDNs, PRAs, FIs, et cetera are done) the Titlebar would contain "Syscob's Export-It Software vA-28a1". As these are the main data entry windows for the application it is absolutely critical that their "base version" ("A-28" in this case) match the database version. Executables that have a version resource will encode the base version and sub-version as indicated in the example at the lower right in the embedded resource as well as having a version string in their window Titlebar.
If a program with a different database version updates the database then the database content will be corrupted! An example of such a mismatch would be a window showing version "W-24a" being used to update the example "A-28" database. In such a case, because "W" does not match "A" (i.e. the database versions differ), database corruption, or a series of field error dialogs, would result from use of the mismatched program.
Knowledge of the current base version installed at a site is critical for two reasons:
In cases where more than one “update” needs to be applied then the starting point, and the sequence of updates, will depend on the current application version. For example, in the "W-24a" case a visit to the Syscob updates page on the web would disclose that two (2) updates are needed to reach version "A-28": an update from W-24 to Y-26 and then an update from Y-26 to A-28. For the purpose of updating the DataFlex version and sub-version components of a version string are not significant; only the base version affects an “update” installer.
Because the base version is critical to updating both the database format and the programs the update "installers" contain protection to prevent erroneous application of an update. For example, an installer intended to update from version W-24 to Y-26 would not execute in a topology that did not have an acceptable database version (W-24 or X-25 in this case). But there are two situations in which the inbuilt protection might need to be overridden:
If the first execution of an update "installer" fails to complete, or when a database file is in use (preventing exclusive access), any needed update of the database format may not have been successful. In such a case the update needs to be re-run after the "Version.dat" files in the "DATA" subfolder of the Database "server" Folder and in the "VDF7" subfolder of the Platform "local" Folder have been deleted.
When a subsequent execution of an installer fails to complete, but when at least one previous run of the update completed without errors, then only that platform needs to have the update re-applied. Such a situation could arise due to a power failure, or a user abort, during an update. In such a case the update needs to be re-run after only the "Version.dat" file in the "VDF7" subfolder of the Platform "local" Folder has been deleted.
The first case, database format update failure, can be detected after-the-fact by field out-of-range, value or format error dialogs when trying to use the RFPs and/or ExportIt modules. The second case, an incomplete platform update, would be exposed by differing versions between the platform not fully updated and the other machines (if any) in the topology. It can be confirmed by comparing the "Version.dat" file in the "VDF7" subfolder of the Platform "local" Folder to that found in the "DATA" subfolder of the Database "server" Folder (the platform file will indicate an earlier version).
