Investigating Enabler Upgrade Issues
Note: If unsure of the cause of the upgrade failure, contact Magenta Support for assistance before continuing
How to recover from an auto upgrade that has partially run but failed
During the upgrade process the system will rename existing files and tables and then copy in new version of the files and tables and then migrate the old with the new. Once this migration is complete a reindex processes then runs across the new tables, occasionally this process can be interrupted and cause the upgrade to not fully complete. Re-running the upgrade process after a failure can potentially cause loss of data so file sizes and modified dates will need to be reviewed prior to re running upgrade.
Unable to open Enabler after upgrade
The application files in the enabler folder require being from the same version. If any of the application files in the enabler folder do not fully or properly migrate then usually a message similar to the following will display when any attempts to open enabler applications are made
This usually indicates one or more of the files are on a different version The original application files will need to renamed back to their original extension prior to re-running upgrade
c:\enabler>ren *.oxe *.exe then c:\enabler>ren *.oll *.dll
Alternatively the *.dll and *.exe files of the previous version can be copied from another till and replaced in the enabler folder. An upgrade can then be re-run to guarantee all files on this machine are on correct enabler version.
Database Migration Failure
NOTE: Database migration failure gets logged in the \enabler\migrate.txt file. Open migrate.txt in notepad to see what database failed to migrate.
Migration takes empty database files from the \upgbase directory (This is a data dictionary of sorts as the files in upgbase hold the latest fresh database files with the latest correct structures from the last upgrade performed – an upgrade needs to have been performed for the \upgbase folder to exist) and puts them in to your relevant local, lantran etc directories. When this process is performed, the data contained in the existing .dbf files is not lost, it is copied/migrated to the new files, thereby extending the file structure definition without losing data. E.G: posprod.dbf has a new database field added to the file structure. The upgrade will place the new version of this file into the \upgbase folder. When the upgrade process performs the migrate, it will take the pre-existing posprod.dbf from the enabler folder as a starting point, and a copy of the new empty posprod.dbf as the ending point. It reads each record from the existing posprod, and inserts it into the new posprod.dbf. The new posprod is the same as the existing one, except that the .dbf now has the new fields as required by the new version of the software. The upgrade process then runs the re-index process to index the new structures.
If this process is interrupted there is a possibility the migration of the tables has failed so re running the upgrade at this point may result in loss of data.
The basic approach would be to review the tables and if the table size of the all the *.dbf files is less that the copies of the *.old version of the tables then the migration has completed successfully, but if the modified date of the *.old files is current and the *.dbf files size are smaller that the *.old then the migration has not successfully occurred.
Rename the *.old tables with data to .dbf then the upgrade can then be reapplied.
Note:It is not enough to just suspend nibbler if upgrading the store server and the tills are trading. The tills don’t need nibbler to write to the store server – the server should be disconnected from the network for the manual upgrade to run with no interference from tills
Upgrade package not found
Note: The following errors are located in the Back Office Event Log at the store under the event type Auto Upgrade (Back Office → Reports → Event Log)
This error could occur if:
- The upgrade pack is not physically in the location \enabler\comms\upgpack folder on the Store or Head Office Server.
- The upgrade path set for machine locally is not correct; refer to Configure the correct upgrade path for all machines
Unable to unzip upgrade package
Nibbler uses dunzip32.dll which should be in the enabler folder. This is a third party DLL which we distribute (both dunzip32.dll and dzip32.dll) to do unzipping and zipping. We call functions from within this DLL to do the work for us.
This error could occur if:
- The upgrade pack is corrupt in some way. Check the file size against the file at Head Office. You might like to re-send the upgrade pack.
- Check to make sure that dunzip32.dll exists in the enabler folder. Try replacing dunzip32.dll from another machine.
Unable to delete or extract upgbase
Upgbase is a folder that is created on the same drive as enabler and contains empty copies of the enabler databases. This folder is created prior to running the upgrade process. If a folder already exists from previous upgrade then this folder is deleted and replaced with a current copy from the new upgrade pack.
It is possible that the \upgbase folder cannot be deleted, possibly due to security reasons.
This could occur if:
- Any of the files within \upgbase are marked as read-only. If so, you need to change them. There is a known issue that could be experienced prior to 4.20. Run the following two lines in a batch file – this will uncheck read-only on all files within \upgbase Attrib –r \upgbase\* /s Attrib –r \upgbase
- The Windows User Account logged onto the store server doesn’t have enough permissions to delete the \upgbase folder. Try deleting the folder manually, if you can’t, the upgrade is never going to work until the machine is logged on by a user with sufficient permissions. Please note that the \upgbase folder is not stored within the \enabler folder.
Examples of security factors include:
- Current logon domain rights
- Current logon workgroup rights
- Permissions granted to the root directory of the hard disk partition containing Enabler
- Possible permissions limitations might prevent deletion of the \upgbase directory.
- Other possibilities include some files being read-only in that directory or simply that some other process had locked the directory or subdirectories and/or files contained therein. This is as simple as having a Windows explorer window open on that directory or a command prompt with current working directory of \upgbase etc.
There is nothing in the event log under auto upgrade
This could occur if:
- The store did not have a valid scheduled time set for the upgrade to run.
- The upgrade instruction/message from Head Office didn’t reach the store in time for the upgrade to run. This can be avoided by scheduling the upgrades well in advance.
Till failed to respond
This could occur if:
- Till/s in the store were powered off at the scheduled upgrade time
- Nibbler is not running on a till. Nibble is required to be running on all tills. Use the Event Log to check if nibbler was shutdown on a particular till prior to upgrade.
- Server contains incorrect information regarding tills in branch environment. ie till physically not in store but till flagged as online in Local setup
- Till is flagged as being offsite
- Tills local configurations files not configured to communicate over the LAN correctly
Missing database Branch.dbf
This could occur if:
- Enabler configuration (.ini) files still reside in the root of the windows directory and permissions are disallowing the moving of these 3 files.
- This only applies if upgrading from a version below 4.04. You would need to manually move these files to the enabler directory, the files are winsuite.ini wshware.ini winpos.ini
- The winsuite.ini file in the tills enabler folder contains the incorrect path for the \enabler\local directory.
Note: The three configuration, Winsuite.ini, Winpos.ini and Wshware.ini files should reside in the \enabler folder on all machines and in \enabler\comms\config folders on a store server.
Errors when generating reports after an upgrade
This could occur if the upgrade did not completed migration or reindexing successfully. Refer to section Database Migration Failure
------------------------------------- Type: Missing Database Date: 20050316 Time: 08:03:06 Logical Address: 021509 Version: 04.25.03 help_idx: 0 d:\enabler\local\TMPCPO.DBF -------------------------------------- Type: Missing Database Date: 20050316 Time: 08:17:19 Logical Address: 021509 Version: 04.25.03 help_idx: 0 d:\enabler\local\TMPCPO.DBF -------------------------------------- Type: Missing Database Date: 20050316 Time: 08:24:58 Logical Address: 021509 Version: 04.25.03 help_idx: 0 d:\enabler\local\TMPCPO.DBF -------------------------------------- Type: Database Error Date: 20050316 Time: 08:55:30 Logical Address: 021509 Version: 04.25.03 help_idx: 2930 Error Getting Field Function: DbaseTable :: GetFieldb () Message: Number is out of range. Filename: d:\enabler\local\posrdb.DBF Indexname: d:\enabler\local\posrdb.MDX Database: LOCAL Error Code: 9985