Vision Support

This section contains details of any common support issues and how they would be checked and resolved. This section will be added to over time.

Vision is not updating

Problem

The likely issue is that the Vision Data Mining process has stopped for some reason.

Resolution

• Log on to the machine and check that the Vision Data Mining processes are still scheduled, using the Windows Scheduler. If not, add or re-start them.
• If they are running, check the logs, found in {Vision}\Scripts\DataMining_*.log or through the Event Log Vision screen. This may point to errors or suggestions that the processes are scheduled by failing when run.
• If the processes are failing, pause all the scheduled jobs and kill any processes on the machine called Wscript.exe using the Windows Task Manager. When complete, start the Data Mining tasks again and force run them.

Vision is not updating WCS data (Log database has been renamed)

Problem

The cause of Vision not updating is is that a user renamed the WCS Logging database manually.

Root Cause Resolution

A script has been provided to do this easier and with Vision unaffected – a shortcut to this is usually in the WCS database folder, called WCS_Archive. When the WCS system has been stopped, simply double-click this script and the database will be archived into the ArchiveDB folder. Vision will be informed of this and take the necessary actions to mine any remaining data from here and continue in the new logging database.

The script is called WCS_Archive.vbs and is usually located in {WCS Program Folder}\Database\Upgrades\Xfer\Scripts.

If installing this manually for a new client, a short-cut is usually placed in the Database folder, with the following parameters in the Target:

"{WCS Program Folder}\Database\Upgrades\Xfer\Scripts\WCS_Archive.vbs" -LDB={WCS Database Folder}\log1.mdb -A -V

Resolution

Note: The Data Mining should be disabled before and enabled after the steps have been taken, or ensure that the steps are taken between data mines (usually every 5 minutes).

To resolve quickly (with possible data loss):

• Enquire on table System_Extracts, to find the WCS Data Mine that is affected. This will be records with:
  • Enabled = "Y"
  • Type = "WCS"
  • DB1_Folder will be the machine name or IP address.
• Edit all records on table System_Extract_Points. Blank (i.e. not Null, Change to value Space, then Delete) the Value field on the records with the following values:
  • Extract = "ra_wcs_new", Field "ID"
  • Extract = "RDT Activity", Field "End"
  • Extract = "RDT Activity", Field "Start"
  • Extract = "Exceptions", Field "ID"
• Apply all changes.

To resolve (with no possible data loss):

• Enquire on table System_Extracts, to find the WCS Data Mine that is affected. This will be records with:
  • Enabled = "Y"
  • Type = "WCS"
  • DB1_Folder will be the machine name or IP address.
• Note the Archive Database folder.
• Log onto the WCS server.
• Find the Log database that the user created and copy into the Archive Database.
• Create a file with the same name as the database, with the additional extension ".archive". For example, if the renamed database is called "log1_12345.mdb", create a file called "log1_12345.mdb.archive".

With either resolution, the next time Vision datamining runs, it will update correctly.

Vision is not updating WCS data (WCS has been moved)

Problem

The cause of Vision not updating is is that WCS Logging database doesn't exist where it did before (i.e. the old machine).

Root Cause Resolution

• Enquire on table System_Extracts, to find the WCS Data Mine that is affected. This will be records with:
  • Enabled = "Y"
  • Type = "WCS"
  • DB1_Folder, DB2_Folder and ArchiveDB_Folder will be the machine name or IP address, which needs to be changed to the new address.

When moved, the Log database may have been recreated as well (check with the WCS team to confirm). To correct:

• Edit all records on table System_Extract_Points. Blank (i.e. not Null, Change to value Space, then Delete) the Value field on the records with the following values:
  • Extract = "ra_wcs_new", Field "ID"
  • Extract = "RDT Activity", Field "End"
  • Extract = "RDT Activity", Field "Start"
  • Extract = "Exceptions", Field "ID"
• Apply all changes.

Adding Extended Extract Parameters

For example:

We have created two new marshalling locations, 'Special Ambient High' picks using truck type MU & 'Special Ambient Low' truck type SP to marhsalling location MASPNO and 'Special OTC High' pick using truck type MU & 'Special OTC Low' truck type SO to marhsalling location MASPOT. So that will be four new Task Type IDs - 'Special Ambient High', 'Special Ambient Low', 'Special OTC High' and 'Special OTC High'

In order to do this, Extended Extract Parameters must be entered on the correct System for the new types, plus existing types should be checked that the marshalling lanes are not in use on them.

• Stop the Vision datamining.
• Start MySQL Administrator and connect to the database.
• Find the System related to the site in question (from table system_extracts).
• Retrieve the parameters from table extended_system_extract for that System.
• Add an OrderType entry for the new extract type as follows:
  • System - as the others for that system
  • Extract_ID - Normally 1 for OrderType extracts, but set to the same as others.
  • Extract_Level - ensure this is greater than the last extract level (excepting any extract level marked as X). For axample, if you already have level 1|1, 1|2 and 1|X, the next created extract level will be 1|3.
  • Extract_Sequence - Number this in Extract_Level sequence, renumbering al following records accordingly. Following the last example, 1|1, 1|2 and 1|X may be sequenced originally as 1, 2 and 3. Adding 1|3 will result in this being sequenced as 3, and the following Level being sequenced as 4. All subsequent levels will also be renumbered.
  • Extract_Name - As requested e.g. "Special Ambient". Note that the "Low" or "High" component is added by a further Extract ID
  • Extract_Field - "To Location"
  • Extract_Values - the marshalling lanes specified.
  • Format - NULL
  • Type - "S" (string)
  • DB_Type - "MSA"
  • Operator - "="
  • Constant - "Y" (cannot be modified by the users)
  • Table - "Truck Move"
  • Extract_Selection - "B" (Both)
  • Category - NULL
  • Owner_Code - NULL
• When all are added, commit the changes.
• Add the truck types required to the specific Extract Types on table system_ext_trucks:
  • System - As the others for that system
  • Extended_Type - The combination of all extract names combined, replacing spaces with underscores. So, "Special Ambient" combined with "High" and "Low" will result in two records, with Extended Types of "Special_Ambient_High" and "Special_Ambient_Low"
  • Truck_Type - As requested. If there are multiple truck types requested, mumtiple records for this Extended_Type should be created.
• When all are added, commit the data.

• Run the Datamining script manually:
  • Check the log file to ensure that everything worked.
  • Check the data to ensure that everything worked (remembering that no data may yet exist for these new marshalling locations).
• Re-start the data mining

Also, it is usually beneficial to ensure any existing raw data already mined in the last few days is also updated. It will have been marked as the Extended Type associated to Extract Level 1|X for that system, and should be changed.

• For each type to be updated, select data from table `RDT Activity` where the `To Location` field matches the marshalling locations expected and the `Task Type` field is "PP". Note: Always confirm the Company and Warehouse values are correct for the records.
• As the data has already had the Extended_Type marked as the default Extract Type by the existing default parameter (including the "High" or "Low" addendum), this is easy to update either manually, or by updating the value with a function. For example, if the default Extract Type is "Wholesale", each record will be marked as "Wholesale_High" or "Wholesale_Low". Update the field with the value REPLACE(Extended_Type, 'Wholesale', 'Special_Ambient').

The next time that data mining is run, these values will be recalculated into the figures, recalculating all values from the raw data.

Inform the client that the Minimum and Target levels for these Extended Extract Types can now be entered through the system.

Disk Full

Typically issues on the machine have caused a crash of the Vision datamine processes.

These are now cyclically logging errors to the ERROR_LOG table in the MySQL database, which will be taking up the disk space.

Checks:

• Check the error log datafile (error_log.ldb) in the MySQL database area, typically C:\ or E:\, Program Data\MySQL\Database\Productivity1\
• If this is large, then it should be truncated.

Solution:

• Start MySQL Administrator.
• Click the box for the database
• Log on to the database (enter password)
• Start a new query:
  • TRUNCATE Productivity1.ERROR_LOG;
• Check that the table's datafile is now small.

Given that the disk is full, you may not be able to access the database to take this action.

So several or all of the following steps may be required, and are typically recommended:

• Stop and disable vision scheduler items.
• Kill wscript processes using task manager.
• Stop MySQL service (may take a while).
• You may need to kill the MySQL service (with Task Manager)
• Clear as much space as you can.
• Start MySQL service (may take a while).
• Truncate the error log as described above.

The disk space is cleared, so any other processes on the machine can now be started.

It is recommended that Vision datamining and cleardown remain disabled for a time, as the MySQL service will be busy catching up.

• Monitor the MySQL process - wait until this is no longer taking up masses of CPU time.
• At this point, stop and start the MySQL service again, to recover system memory and clear MySQL-specific logs.
• Re-enable the Vision scheduled processes.
• Start the Vision Datamine (NOT THE CLEARDOWN)
• Monitor this until finished - typically this will take a while.