Download Release Notes - Logistic Engineering Services

Application: eMRD 5692
Issue No: 1704
Date: 09-Feb-15
Need to implement table level Business Rules checks
Implemented a method of checking all the relevant table level Business Rules as defined in DI(AF)5692.
Most of these tests are stored as SQL statements in a new 'ControlData' database, but some required more complex code.
For many of these tests, there is one or more possible fixes which can be applied across the whole WSDB and are also
stored as SQL statements in the 'ControlData' database.
Many other errors cannot and should not be fixed across the whole database and will necessitate the user making changes
through the normal editing screens.
Access to this new functionality is via a new tab on the View Tables form (this was chosen because of the similarities in
viewing tables, running Adhoc Queries and the new Business Rules tests).
Results are presented in the View Tables grid and can be exported in the various formats that the form provides.
The tests are broken up hierarchically by table and can be run in the follwong ways:
1. all test for all tables;
2. all tests for a group of tables, eg all the A tables;
3. all test for a particular table, eg HA; or
4. a particular test for a particular table.
If option 4 is chosen, the errors (if any) are listed in the View Tables grid and a Fix error button is enabled.
Clicking the Fix button will show a list of pre-defined fixes (if there are any).
Selecting a pre-defined fix places the corresponding SQL for the Fix into the Adhoc Query window, where it can be modified
or run as is.
If test options 1, 2 or 3 are chosen, all the necessary tests are run and any tests which find errors show up as red in the tree
of tests.
The red ones can then be run individually to present the grid of errors and gain access to the Fix button.
Between these tests and the Anomaly Validations and Orphan checks, users should be able to catch (and fix) virtually all of
the defined errors in their databases.
Notes:
1. The ControlData database exists as an MSAccess database in the eMRD installation folder;
2. Some other control and reference tables that used to live in the LSABlank database have been moved to the ControlData
database, eg the Lookups table which feeds the allowable values Picklist form (this has been done in an effort to minimise
the number of times that the structure of the LSABlank database changes); and
3. Because of the importance of the data in the ControlData database, it SHOULD NOT be messed with.
Issue No: 1709
Problem when validating licence key in non Australian region
Modified the code for the licence expiry date validation check to make it independent of region .
Issue No: 1723
Addition of Int/Events field to task editing screen
Added Servicing Int/Event to the Servicing Links list on the Task Edit screen.
Also added Servicing Int/Event to the popup list of Servicings when adding a Servicing link on the Task Edit screen.
Issue No: 1724
Unable to delete end item SNoUOCs (Version 3.1.1)
Any related records should also be deleted from tables HN and WJ.
Issue No: 1725
Addition of nomenclature filter to View Tasks tool
Added a Nomeclature Filter option to the View Tasks form.
This allows finding of tasks by filtering on words in the Nomenclature field.
Issue No: 1736
Incorrect heading on EE508 report
Fixed the heading of the Discrepancies column of the EE508 PSS report to bring it into line with AAP7001.038(AM1) AL3.
Issue No: 1737
Modify the Master/Slave Tasks Claimed Activities and Init Conds check
The anomaly checks for Initiating Conditions and Claimed Activities on Master/Slave task combinations have been changed.
The checks are now done separately.
The Initiating Conditions check compares the numbers and types of Initiating Conditions between Master tasks and their
Slaves and reports on differences.
The Claimed Activities check compares the numbers of Claimed Activities between Master tasks and their Slaves.
8
of
51