Table of Contents

MDxBUT - Static Data System

Available Functions / Implementation Approach

In order to ensure a clear and secure loading and locking of dependent data, the following functions are provided in the static data environment:

  1. MDxBUT determines additional configuration information by calling all methods with the generic name “GetSprAddConfig” in/under \RECPAN.
  2. By calling “SprModuleInclude( Instance )” “i”n “GetSprAddConfig” one module instance can be registered respectively. This instance will then be checked automatically against changes when it is picked up again. If changes are determined in the instances registered this way, an automatic update is discarded in the 4-eye control. In this case it is also prohibited to take up an interrupted transaction. The main record of the REC linked to MDxBUT will the be registered automatically by MDxBUT.
  3. As a second configuration option, one field at a time can be registered in “GetSprAddConfig” by calling “SprModuleKeepField”, which is not subject to the modification check. In this fields, the data is received automatically via SPRMOD and calling GETADDSUB. The data is not set to the picked-up SP, i.e. the fields marked this way remain in the database status and lose the content saved in the SPT after being picked up again.
  4. Within the context of the Init, MDxBUT calls the optionally specified method in \RECPAN\RECGET\GETADDSUB. This rule reads all dependent data of the already loaded REC.
  5. MDxBUT automatically locks the main record of the linked REC.
  6. MDxBUT checks all instances registered with “SprModuleInclude”, whether they contain INR or REC\INR as INR field. If this is the case, these instances are locked automatically.

As a result, the “xxxP” has to “Know-How”, which additional data have to be read.

With this approach, the following items can be implemented:

a) A submodule, that is e.g. filled from INI files, can be filled in the method specified in GETADDSUB. In case these INI data is also changeable, this submodule can also be registered via “SprModuleInclude”. As a result, the modifications are saved via [Break] (example: USRSEC in USRP).

b)If fields within a static data file contain technical data, that cannot be edited interactively, these files can be excluded from the modification process in the static data and can be registered by using the 4-eye principle by calling “SprModuleKeepField” in “GetSprAddConfig” (example from the USR table: LSTDIADAT, SSNBEGDAT, SSNBEGTIM, SSNINR).

c) If an additional records has also to be edited, the module instance containing this record can be loaded into the method specified in GETADDSUB and can be registered via “SprModuleInclude” (example PTY + ADRMAA).

d) In case a grid with a variable number of additional records has also to be edited, the grid can be filled in the method specified in GETADDSUB. Instead of registering all instances individually via “SprModuleInclude”, the module instance containing the grid can also be registered via “SprModuleInclude” (e.g. PRTMOD).

At the moment, optionally a recordgroup or a record (for tables that have no group) can be linked to MDxBUT as REC. At present, the whole group is saved, when [Break] is clicked. Both properties remain unchanged.

If the method specified in GETADDSUB is called, the main record of the REC linked to MDxBUT is loaded and locked at that time.

  1. Defining the entry (usually determining its INR)
  2. If the data are not read out of the database, the module that picks up the data has to be deleted, so that all the Modified attributes are also deleted.
  3. Reading data (from database or via “GetIni” or any other way)

Restoring the the SPT status is automatically done by SPRMOD after calling the method specified in GETADDSUB.

Note: In this procedure, defaults for setting initial values cannot be used, if records to be edited are selected depending on the values.

Further details about the implementation of the 4-eye control (also, 4-eye principle) can be found under '4 Eye Control - Implementation' and '4-Eye Control - Technical Aspects'.

Modules in use

Module Description Alternative Instance Name
xxx Table description REC
xxxGRP Optional structure module to combine the additional information belonging to a table RECGRP
xxxP Panel module RECPAN
xxxGET Searching / reading a record RECGET
DBIxxx Displaying and selecting a transaction
DBAxxx Add new
DBExxx Editing
DBDxxx Deleting
DBLxxx Static data report
INFxxx Info - Searching and displaying
MDIBUT Base logic for DBIxxx displaying transactions
MDABUT Base logic for DBAxxx Add New transactions
MDEBUT Base logic for DBExxx editing transactions
MDDBUT Base logic for DBDxxx deleting transactions
MDLBUT Base logic for DBLxxx report transactions
INFBUT Base logic for INFxxx Info transactions
SPRMOD Module implemented into the BUT modules for handling the 4-eye principle
SDAMOD Module implemented into the GET modules for handling Drag&Drop and DDE
PRFMOD Optionally used module for profile editors. It automatically creates an additional panel for all fields that are not placed on a panel yet.

Which items have to be implemented where?

Description Location
Setting the edited object ( \SYSMOD\OBJNAM ) “xxxP.Default \SYSMOD\OBJNAM global”
Preparing to create a new item by deleting the complete record except the key field in unknown records.
The Modified attribute has to be set for key fields that will not be deleted and which are changeable. As a result, an externally defaulted key field will be marked as registered/modified when saving the generated Display file. 		“DBAxxx.Init”
Reloading of additional records/data. This could be unchanged records like, for example, for displaying longtexts or also records to be modified directly (e.g. main party address or the printer configuration in the user administration. “xxxP.<getadd>” method set x“xxP\RECGET\GETADDSUB” to ..“\<getadd>”
In case data out of additional records are also to be changed and that they are protected against other changes during the editing process. xxxP.“SetSprAddConfig” to complete “SprModuleInclude”
If additional records are also to be stored permanently Create “DBAxxx.Event MDABUT\SAV” with storing function Create “DBExxx.Event MDEBUT\UPD” with update functionCreate “DBDxxx.Event MDDBUT\DEL” with deleting function
If additional deleting conditions are to be checked Create “DBDxxx.Check <chkfld>” by using “MDDBUT.ChkRecFnd”.
The technical field plausibilities “xxxP” check in consideration of PANSTA
(usually “if PANSTA = PanStaEdit” or “PANSTA = PanStaAdd then”)
If an additional record of table ADD is linked via INR and it should be selectable via a GET. “xxxP\ADD” is an ADD instance. In “xxxP” an ADDGET is implementedIn the Init of “xxxP” the “ADDGET\SDAMOD\LNKRECINR” has to be set to “\”\RECPAN\\RECGRP\\REC\\ADDINR“”“xxxP”.Default ADD with reading ADD resp. ADDINR

Things, that are often forgotten during the implementation

When transactions that have been interrupted with [Break] are reloaded, only the REC/RECGRP linked to MDxBUT and the modules registered via “SprModuleInclude” are restored. For all external data it has to be ensured that they are loaded in their current status.

Only in fields that are located within REC/RECGRP or within the modules registered with “SprModuleInclude”, the Modified status is saved via [Break] or the 'Dummy Save' when the 4-eye principle is enabled.

If a key is defaulted externally in a Add New transaction, it should be marked as “Modified”, as it is not defaulted by the system (even if this is the case from the technical point of view).

When using the 4-eye principle, a Display image is saved. It shows all panels in their current state, even if they are not been edited. If, due to performance reasons, a mere display panel is filled not before the “PanelEnterEvent”, this panel is taken over without any data into the DSP file.