Caution: The below documentation describes the get modules implemented in DOKA 5 and not in DOKA-NG.

The following steps are required to use a GET in a panel:

1. Insert the GET module into the panel module.
2. Linking the Record (REC) or the RECGRP\REC as an argument into the GET.
3. Drag the key fields with viewtype combogrid and the Info button onto the panel and position the elements correspondingly.
4. Write a default rule in which DISSEL of the GET depending on PANSTA is set in all those cases where no access should be possible.
5. If dependent records (e.g. a GRP) have to be filled with data, please insert a corresponding rule into GETADDSUB. NOTE: Modules outside the GRP have to be marked as changed with RECALC, so that the dependent defaults are executed.
6. Please check, if a CLSFLG has to be set. You can set it, if necessary, in the INIT or via a default rule.
7. If there exist PNT fields in the GET please make sure, that these fields are filled in accordingly.
8. In case additional search conditions have to be defined, SELSQL and SELTXT have to be specified according to 'Additional Search Conditions in a GET'.

The control of GET fields or of the linked in SDAMOD fields from one level below, which were dragged onto the panel depends on the connection of the GET with the panel or with the REC.

1. The GET allows to select an entry, which is part of the key of the main entry.
2. The GET allows to select the main entry.
3. The GET allows to select a subordinate entry associated to the main entry.
4. The GET allows to select entries, which data can, for example, be used for evaluations or other purposes.

The following table lists the values to be used in static data maintenance transactions divided into the four types mentioned above. The normally used rules are marked bold.

(a) The set can normally be deleted, only if the set depending on other fields or switches cannot be selected - disable the fields marked with an (a) or disable the access function by setting DISSEL.

The associated subsets belonging to (3) can basically be loaded in two different ways.

1. Via a default rule, a Read can be executed, depending on the field(s) of the main set. In this case, the reload via the rule entered in GETADDSUB can be omitted.
2. A reload routine can be called in the INIT after reading the main entry. This rule is then also entered in GETADDSUB of the GET of the main entry.

1. A GET provides an access method that enables the user to select and load specific data objects.
2. Available access modes:
   1. Direct access by entering a unique search key.
   2. Indirect access by entering non-unique search key and using the selection list after that.
   3. Importing via the D&D receiver.
   4. Receiving data via DDE connection from the DDE server (Info System).
3. Icon and control of the D&D sender / D&D receiver is managed by the GET.
4. The GET knows the mapping how to search the table columns with the entered search key.

The GET contains SDAMOD to support the D&D and DDE functions.

The GET provides a field called DISSEL. You can deactivate the select / receive function via this field.

The precise record instance the access should take place will be passed on to the GET.

The GET has an internal control variable (usually OLDKEY), in which the last successfully loaded key is saved (independent from the fact whether the GET or another routine has read the data record).

PLEASE NOTE: The field length of the control variable must be in accordance with the field length of the key.

The main key has multiple event rules:

• Order 100 - Checks, whether DISSEL was set or the key value remained unchanged.
• Order 900 - DB access or deleting the record depending on the event type and the access result.
• Order 1500 - If the REC is a component of a xxxGRP, a special logic with RECALC and REDISPLAY for MDIBUT has to be available.

There is a default rule for the internal control variables filling in the field from the REC if the REC was loaded (i.e. the INR was set).

A check rule is available for the D&D sender. This rule generates an error message if a not loaded data record should be passed by D&D.

In the INIT the values of DADSND have to be set to make sure that the correct icon is displayed and that D&D works accordingly with the GET. The DADRCV value can also be set there, if the GET has to process a value that varies from the linked table.

The DADRCV contained in SDAMOD is activated (enabled) or deactivated (disabled) in a default rule depending on DISSEL.

The combination of the fields and the access type can be defined in the rules “CreateReadSql” and“CreateSelectSql” on Security Level 5. In this way the database access can be adapted specifically for each installation.

In GET functions it is possible to show (or not to show) the respective data records (Contracts) in the display.

For this purpose another interface field CLSFLG (besides DISSEL) is provided in the respective GET module. It can have three different values.

Empty (empty = default value) → In the selection list only open contracts will be displayed.

'C'losed → In the selection list only closed contracts will be displayed.

'A'll → In the selection list all contracts will be displayed.

Please note, that the switch (CLSFLG) checks only the display in the selection list and not the usage. Thus it is possible to take or read contracts via DDE or Drag & Drop not matching the switch setting.

If a transaction was enabled to open only specific contracts, it has to be controlled via the transaction that only those contracts are processed which correspond to the conditions.

The switch can be set either statically (always a fixed value) or dynamically (value depends on other data or entry fields) out of the transaction.

Even if only not logically deleted contracts are displayed in the selection list, the appropriate contract must be read when the complete reference number is entered. The switch has to reduce merely the content of the selection list. It is also possible, where necessary, to switch over to other states via the context menu or via hotkeys.

This extension of the GET applies to all tables allowing logic deletion of data records (for example: all contracts).

It is possible to reload dependent records. This can be done by entering a rule name into the field GETADDSUB. Thereby, a rule will be called by the GET, whenever the GET deletes or loads the linked record.

This rule is called in the following cases via a synchronous post:

1. Selection of a data record by a user
2. Selection of a data record received via DDE
3. Selection of a data record via D&D receiver

In order to ensure the correct processing when receiving a DDE message (so that GETADDSUB can also be called), the “sub HandleDDEReceive” method has to be included in the GET. This method makes sure that the correct processing steps are executed in the GET.

SYSMOD calls the routine HandleDDEReceive automatically, if it is available.

A GET uses these interfaces to communicate with its environment:

• Fields
  • DISSEL - Disable Select - Switches off the interactive search/read functions of the GET
  • GETADDSUB - Additional Subroutine - For reworking and reloading dependent data records (please keep in mind the RECALC of these modules)
  • In parts CLSFLG - Close Flag (all or only opened and/or only closed)
  • In parts PNTTYP - Parent Area - Reduces the selection list
  • In parts PNTINR - Parent Contract - Reduces the selection list
  • In parts PNTREF - References of the parent contract (if PNTINR is set)
• Rules
  • “Event xxx\EXTKEY” (and/or key field) / Do not use externally. The external use is the old technology!
  • “RecReadRecord” - Method - Standard process to load an external data record.
  • “HandleDDEReceive” / Internal interface of SYSMOD.DDEReceive. Do not use externally. The external use is the old technology!
  • “Event SDAMOD\DADRCV” / Do not use externally. The external use is the old technology!
• Link
  • REC res. xxxGRP\REC
• Panel Objects
  • Key field(s) out of REC
  • Info button SDAMOD\SEAINF
  • Drag&Drop icon SDAMOD\DADSND
  • Drag&Drop receiver SDAMOD\DADRCV
• Customizing a GET
  • “CreateReadSql”
  • “CreateSelectSql”

The main function of a GET module is to make a data record of the database available for the application.

If a value is to be selected out of an set of data you can use “GET” or “Combobox” as standard processes.

The GET standard process will be used if you want to select a data record from the database. Exceptions are database tables with few known values. Here it is allowed to use a combobox. The selection of data records per combobox in DOKA 5 should only be done for CTY, CUR, and REG. All other data records have to be selected via GET.

Comboboxes are also used for selecting values out of technical or banking codetables (which are not permanently connected to a database table).

Theoretically, a combination of GET and Combobox is possible, but due to several reasons it is not allowed. If you try to use both features at the same time, several technical problems will occur. Therefore it was agreed to forbid this combination.

Exception: A key of a database table consists of multiple subfields and one of these subfields is a technical switch (e.g. object type). A combobox can be used for this technical subfield as selection feature here. In this case you have to trigger the data selection for the GET, when you exit the combobox. Thus, for such cases it is allowed that a combobox can trigger a GET or that a combobox is linked to a GET at the same time. The GET, however, always loads a complete data record with all subfields of the respective key.

Example: The following three guarantee texts ENOCP, ENOCP0001, and ENOCP0002 are available.

The user enters ENOCP. What is supposed to happen now?

It is NOT supposed to happen that the exactly matching data record ENOCP is used.

It is NOT supposed to happen that the selection list of the three generic matching data records is displayed.

It is supposed to happen that the selection list displays in some way or the other the respective data records (in this case these three data records). (If there is another data record available, where ENOCP occurs somewhere in the NAM field, this one is also displayed.)

In DOKA 4 all entries were strictly generic search values, i.e. the searching and comparing was always performed from beginning to end. Furthermore, in DOKA 4 there was exactly one matchcode a generic search was performed. As a result in DOKA 4 only the selection list with the three entities would be displayed (Case b).

In DOKA 5 the entry values are not generic any more, i.e. the entered value can also occur somewhere in the back of a key or a NAM field (also in other fields, depending on the table). There is also no matchcode any more.

The search function implemented at the beginning detects a data record which matches exactly the entered key value. This match will be displayed without any other hits. In case exactly this value is not available, a selection list with all somehow matching/corresponding data records is displayed. This selection is also displayed, even if an exact match is available.

Basically, all search requests are case insensitive. According to this, an entry of the values “ENOCP”, “enocp”, “EnOcp”, “Enocp” leads always to the same result.

As a consequence, two search commands have to be implemented in a GET.

1. A READ, which, for example, accesses the database with the following SQL condition:

“SqlFldUpper( EXTKEY ) like SqlLitUpper ( '%' + $Key + '%' )”

If the output of the first access is “TdOdbcNotFound” or “TdOdbcNotUnique”, a second SELECT with interactive selection has to be called. The first access must contain the Multi Entity Logic.

2. A SELECT searching multiple search columns on the basis of the entered keys. Usually this is a DbSelect only searches the primary key field, the NAM field and an external reference number (if available). This second access must also contain the Multi Entity Logic.

If the field PNTTYP ((Parent Type) [Example: LID]) will be set in a GET, only those data records are displayed matching the parent type of the field content of PBTTYP.

The subcontract to be called via the entry of a complete / unique reference number may be read at first internally independent from the parent check. If there is a subcontract not belonging to the parent indicated, the user has to be informed via prompt that the subcontract belongs to another main contract. The user can then decide, whether the main contract should be changed (reloaded = default setting) or whether the selected subcontract should be discarded.

Even if a contract has been passed via DDE or D&D, nevertheless this check and the optional prompt have to be carried out.

From the technical point of view this means, that the hard parent check may only be carried out in the selection list of the GET. The GET itself does not ensure, if a read subcontract is suitable to the parent. This check has to be performed in the modules/transaction using the GET. The same applies to the display of the prompt, for the reload of the parent (depending on the user selection) or for the deletion of the subcontract.

A usually case insensitive search will be performed in the database for the entered value.

At first it is searched for exactly that data record, containing the entered value in the main key term (the internal technical fieldnames are mostly EXTKEY, OWNREF, or COD). If there is only exactly one data record, this one will be taken and will be read as a search result.

The selection list is used to select data records, if there is no data record or if there are multiple data records. In the selection list all data records are displayed containing the entered values somewhere in the main key, the description field or in other fields reasonable to search in (depending on the table). All search fields have to be displayed in the selection list. Further search fields should be added restrictively, in order to keep the search result comprehensible. You can use the info system to search with its enhanced search functionality.

The special character “?” is used in every search to call the selection list with all respective data records.

The search has to be performed, if the entry field was changed or no data record is read. You start it by pressing the [Enter] key or if you leave the list by clicking the [Tab}or [Backtab] key. If you click with the mouse in another field or on another button causes merely a deletion of the respective data record, after the entry field was changed. Using a hotkey or a shortcut has the same effect.

In searches, where no data record was found or in searches where the selection list was skipped or canceled with [Esc], an error message (yellow box) next to the entry field should be shown. As a result the cursor should be active again in this field.

If you search for contracts it is also possible to limit the search to 'only active' or 'only closed' contracts. By default, a search for only active contracts is performed.

In Contracts belonging to a parent contract, the search can be limited to all subcontracts of this parent contract. If this is not defined, it is a normal contract search. In this way it is possible, to display e.g. all claims of a guarantee very quickly with “?”.

In case the Multi Entity is active, the search is always limited to the entity and/or the entity group, which is mapped to the user. This depends on the basis the table was defined.

If you enter a unique part of the reference number or customer reference number, normally the data record will be read without selection list.

Selection lists containing only one element are not available.

If additional conditions should be considered in the search, those conditions can be specified in the respective GET via an SQL expression in stream SELSQL. In order that the business meaning of this additional condition can also be considered in messages, the second text variable SELTXT is used, in which the plaintext description of the condition can be entered.

The additional 'Where' part entered in SELSQL is (if filled in) attached to the 'Where' part used for the selection list (linked with AND).

Therefore, the 'Where' part can also be an 'xxx in (select yyy from ….)' construction. In the same way, restricting conditions can freely be formulated and have not to be provided in the GET.

PLEASE NOTE: The stream SELSQL and the text field SELTXT will not be deleted automatically from the respective GET. If the stream in a transaction is to be set in different ways (depending on the data), it should best be implemented via a default rule, so that data modifications are also be considered in the condition. In case of static (not data-dependent) conditions both variables can be set in the INIT.