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:

1. Add the GET module to the panel module.
2. Add the SHW module to the panel module.
3. Include in the GET the record (REC) or the RECGRP\REC as an argument.
4. Drag the key fields with viewtype “combogrid”, as well as the SEAGET button, onto the panel and position them accordingly (or as a column in the grid row).
5. Write a default rule to set the GET DISSEL to be driven by the panel PANSTA of the panel in all cases where you want access to be disabled.
6. In case dependent records (such as a GRP) are to be populated with data, add a suitable rule to GETADDSUB. NOTE: modules outside of GRP need to be flagged as modified using RECALC for dependent defaults to execute.
7. For contracts: check if a CLSFLG needs to be set. If so, use the INIT or a default rule to achieve this objective.
8. If the GET contains parent fields (for contracts), ensure that these fields are populated accordingly.
9. If you need to define additional search criteria, populate SELSQL and SELTXT according to the directions in “Additional GET search criteria”.

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).

1. The GET allows you to select an entry that is equivalent to part of the key of the main entry being edited.
2. The GET allows you to select the main entry.
3. The GET allows you to select a subentry to the main entry.
4. The GET allows you to select a set whose data may be subject to evaluation or other purposes.

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.

(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):

1. Run a read operation using a default rule, depending on the main set's field(s). There is no need in this case to re-load using the rule entered in GETADDSUB.
2. After reading the main entry, call a re-loading routine. This routine needs to be entered in the main entry's GETADDSUB.

1. A GET provides method of access permitting a user to select and load a certain data object.
2. Two methods of access exist:
3. - Direct access entering a unique search key
4. - Indirect access entering a non-unique key and then selecting from a list of matches
5. GET will know which table columns to search, and how to search them, given the search key entered.

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:

• Order 100 - check if DISSEL was set or the key value is unchanged
• Order 850 - read the record in the row selected
• Order 900 - database access or deletion of the record, depending on the type of event and the result returned by the access operation.
• Order 1500 - If the REC is part of a xxxGRP, there needs to be dedicated logic for MDIBUT with RECALC and REDISPLAY.

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:

• Empty (default) → The selection list will show open contracts only.
• 'C' (closed) → The selection list will show closed contracts only.
• 'A' (all) → The selection list will show all contracts.

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:

1. Selection by the user of a record
2. Selection of a record received via DDE.

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.

• Fields
• * DISSEL - Disable Select - disables GET's interactive find/read capabilities
• * GETADDSUB - Additional Subroutine - for loading and editing dependent records (note RECALC of these modules)
• * In part, CLSFLG - Close Flag - display all vs. open vs. closed contracts
• * In part, PNTTYP - Parent Scope - restricts the selection list
• * In part, PNTINR - Parent Contract - restricts the selection list
• * In part, PNTREF - Parent Contract Reference (if PNTINR set)
• Rules
• * “RecReadrecord” - method - standard procedure to load a record externally
• Link
• * REC or xxxGRP\REC
• Panel objects
• * Key field(s) from REC
• * Magnifier button SDAMOD\SEAGET
• Customer specific GET customization
• * “CreateReadSql”
• * “CreateSelectSql”

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.