The documentation for functionality within DOKA 5 can be found under The GET - Access Function of DOKA 5.
In order to use GET in a panel, perform the following steps:
How to control the fields dragged onto the GET or the SDAMOD below depends on the connection between the GET and the panel (or REC).
The following table lists the values normally considered reasonable for the four types mentioned before. The rules normally to be written are marked in bold type.
(1) Field with its own GET, composite key | (2) Key | (3) Key for subentry | (4) Key for separate entry | |
Panel fields | Panel field is independent. | Panel field is independent. | Panel field is not independent. | Panel field is not independent. |
EXTKEY / COD | Enable: If PanStaAdd or PanStaInquiry | Enable: If PanStaAdd or PanStaInquiry | Is normally activated by panel control. | (a) |
SEAINF | Disable: If PanStaShow | Disable: If PanStaAdd or PanStaShow | Disable: If PanStaShow | (a) |
Other GET controls | ||||
DISSEL | blank: If PanStaAdd or PanStaInquiry | Set by MDxBUT or MPxBUT | blank: If PanStaAdd or PanStaEdit | (a) |
GETADDSUB | Name of a routine setting the field in the main entry | Optional: name of a routine if entries dependent on the main entry need to be loaded | Name of a routine setting the field in the main entry | ./. |
(a): Only delete the set, and disable the fields marked “(a)” (or disable access by setting DISSEL) if the set cannot be selected, depending on other fields or flags.
There are two methods for loading partial sets for (3):
GET itself contains SDAMOD, with the field SEAGET (icon ).
GET provides a field entitled DISSEL, which can be used disable the selection feature.
The concrete instance of a record, which the access is to process, is passed to GET.
GET itself features an internal control variable (in most cases, OLDKEY), which holds the most recently successfully read key (irrespective of whether GET itself or another routine read the record).
NOTE: The field length of the control variable needs to be equal to, or greater than, the key's field length.
Several event rules exist for the main key, SEAKEY:
There is a default rule for the internal control variable designed to populate the REC filed once the REC is loaded (i.e. the INR is set).
The selection of fields, as well as the mode of access, can be defined using the security level 5 rules CreateReadSql and “CreateSelectSql”. This allows you to customize database access on a per installation basis.
The GET functionality enables the user to show or hide logically deleted contracts when displaying records (contracts).
In order to achieve this, in addition to DISSEL another interface field, CLSFLG, is provided as part of the GET module. CLSFLG can take any of the following three values:
Please note that this flag (CLSFLG) only checks the selection list displayed. It does no validate usage. Using DDE, for example, it is possible to accept and read contracts that do not match the flag setting.
If a certain transaction is supposed to only process certain contracts, the transaction itself needs to be controlled accordingly in order to ensure that only contracts matching your criteria will be processed.
The transaction can set the flag statically (i.e., to a constant) or dynamically (value dependent on other data or input fields).
Even if the selection list only contains contracts not logically deleted, it should be possible to read the relevant contract from the complete reference number entered. The only purpose of the CLSFLG flag is a reduction in size of the selection list. As an optional feature, the system might enable moving to a different system state using the context menu or hotkeys.
This GET extension will affect all tables that support logical deletion of records, e.g. contracts.
In order to update or load dependent records, it is possible to add the name of a rule to the field GETADDSUB. So doing will cause GET to call a rule whenever GET deletes or loads the linked record.
A synchronous post will thus call the rule in the following scenarios:
In order for GET to process correctly a DDE message (and call GETADDSUB), the GET call needs to contain the “sub HandleDDEReceive method”. This method will ensure that the processing required by GET eexecutes.
SYSMOD will automatically call the “HandleDDEReceive” routine when available.
There now follows a listing of interfaces used by GET to talk to its environment.
If a value is to be selected from a data set, GET or a comobox are available as standard methods.
If a database record is to be selected, GET is the standard method unless the database table contains few and previously known values. In such cases, the use of a combobox is acceptable. Under DOKA-NG, record selection by combobox should be practiced for CTY, CUR and REG only. All other selections should use GET.
Comboboxes also select values from technical or topical codetables (if they are not hard-coded to be associated with database tables).
While using GET and comboboxes in combination is possible in theory, various reasons mean that such combinations are unfeasible. Various technical issues result. We therefore took a decision to prohibit such combinations.
Exception: If a key in a database table contains multiple partial fields, one of which is a technical flag (e.g. an object type), it is possible to use a combobox for selection on this technical partial field. In most cases of this type, exiting the combobox needs to trigger GET for record selection. Thus, in the context of such exceptions a combobox may be associated with a GET call. The GET however will load a complete record in any case, including all partial fields of the key.
Example: Let ENOCP, ENOCP0001 and ENOCP0002 := three guarantee texts
Capitalization will not matter when searching. As such, entering “ENOCP”, “enocp”, “EnOcp”, or “Enocp” will produce identical results.
When entering characters into the search field, all records which contain matching strings within the normalized search field GETFLDNRM will instantly be displayed as a selection list. Any additional input will reduce the list of matches accordingly.
If a parent is externally added to a GET, operation should have the parent restrict the list of selected contracts, analogous to CLSFLG.
Nonetheless, the system should first read the subcontract called by entering a complete and unique reference number, independent of parent validation. Subsequently, if processing a subcontract not associated with the current parent contract, DOKA should open a prompt to inform the user that this subcontract belongs to another master contract. This approach will enable the user to decide if he wishes to load another master contract (default) or reject the currently selected subcontract.
This check and the prompt also need to happen if the contract was passed by DDE.
In technical terms, this requirement means that internal to GET the rigorous parent validation must operate on the selection list only. The reason is that GET itself does not ensure an accurate parent-subcontract match; therefore, the check needs to happen at the level of the modules/transactions using GET. The same reasoning applies to the prompt output, loading the parent (depending on the user's choices) or deleting the subcontract.
The value entered will normally trigger a capitalization agnostic database search. (Note that DOKA-NG offers the additional “advanced search” feature that relies on clicking the magnifier icon, opening a pop-up dialog.)
The system will initially determine if there is exactly one record containing, at any position, the input string as part of its main key construct (the internal technical field names mostly used being EXTKEY, OWNREF or COD). If there is precisely one matching record, it will be read and will constitute the search result.
If there is no such record, or if the search returns several records, the selection list serves to select a record. The selection list will display all records that contain the value entered anywhere in its main key, its identifier field, or any other fields suitable for searching (depending on the tables involved). The search list should display all search fields. Adding further search fields should use some restraint in order to keep the result set clear. Further search features are available from the info system, as well as the advanced search noted above.
The special character '?' is provided as part of the search process in order to call the selection list with all matching records.
Searching is necessary following changes to the input field or if no record is present. A search starts on confirming a field by hitting Enter/Return or by exiting a field (by tabbing or backtabbing). Clicking another field, or a button, will only delete the current record as soon as any change to the input field occurs. The same is true of using a hotkey/shortcut.
A search that did not return any records, as well as a skipped or canceled selection list, should result in an error reported inside a yellow box next to the entry field, returning the focus to this field.
When processing contracts, the application additionally enables a search restrained to active vs. closed contracts. By default, the application only searches for active contracts.
When processing contracts associated with superordinated contracts, the application may load the superordinate contract and constrain the search to all subcontracts of this contract. If undefined, the search will be a normal search on contracts. For example, it is possible to browse all claims of a guarantee using the '?' character.
If multi entity mode is active, searching will always be constrained to the user's current entity and/or entity group. This depends on the definition of the relevant table.
Entering a unique part of the reference number or customer reference number will normally read the record without producing a selection list.
Selection lists with a single element do not exist.
If a GET is supposed to evaluate additional search criteria, it is possible to register them by including in the SELSQL stream a suitable SQL expression. For the content of this additional criterion to be available in messages, the system will use the second text variable SELTXT, where it is possible to enter a plain text description of the search criterion.
The “where” clause included in SELSQL when populated will have an AND operator added and be attached to the “where” clause used for the selection list.
As a consequence, the “where” clause may be constructed as “xxx in (select yyy from ….)” Thus, it is possible to define restraining criteria freely instead of having them included in the GET.
NOTE: A GET call does not automatically delete the SELSQL stream nor the text variable SELTXT. If in a transaction the stream is to be set as driven by the data, the best approach is to implement this requirement by defining a default rule. In this manner, it will be possible to reflect in the criterion any changes to your data. If the criteria are static, so are not subject to change in correlation with changes to the data, it is possible to set both variables within INIT.