Functioning (Import / Export)

Description

The import and the export are carried out by means of a process generated from the template compilation. This temporary process has the name WWINNNNNN or WWENNNNNN (NNNNNN being an incremental number). The process is not deleted if before the launch of the import, the variable GTEST is set to 1.

In the case of an export, the process only extract data (filtered according to the user authorizations). In the case of the import, the process contains the instructions for decoding the data flow and calls the different functions linked to the OBJect to be imported by emulating the entry in some ways. Thus the standard labels for the SUBXXX and SPEXXX processes, which are used to manage the OBJects are named normally.

Additional labels specific to the import are called, to be written in the standard process IMPXXX, or in the specific/custom process associated in the import template.

For the import, the supervisor automatically processes the creation and update of the principal table; and the additional tables can be updated, if this has been programmed in the OBJect actions for example.

For the export, the texts stored in X3, in the form of a clob must be in complete text. If an attempt is made to export a rich text, the text with all its attributes will be exported.

The import and export processes can use the variables GIMP(n).

The documentation for the 'import/export templates carries additional information.  

Import cycle

1- Before simulation of the entry

   Loading of the intermediate [F] class by the record to be imported

   If the record exists in the database, the supervisor loads it in the [M] class.

2- During the simulation of the entry (the fields are processed one by one). 

   The actions on the execution fields "always" or "import/batch"are executed. They are not executed for example, that of a contextual menu (Click, Button, Selection).

   For the fields that can be entered, the [M] class for the fields is loaded by the intermediate [F] class before the control, after_field and after_modify actions.

3-The update transaction

   Loading of the final [F] class for all the [M] class.

   Creation or update of the principal table for the OBJect

   The additional tables are processed by the action for the next OBJect : MODIFICATION

Entry simulation characteristics

The actions on the execution fields "always" or "import/batch"are executed.

The mandatory fields must be loaded.

There is no automatic Trans-class for the displayed or invisible fields.

The fields are processed in the order of their definition in the screen.

An additional action is available in import on the fields that can be entered : IMP_ZONE on the list section fields, IMP_TAB on the grid section fields planned for a detailed table.

Import template without OBJect

In this case, the supervisor does not use the [M] class for the masks associated with the OBJect. There is therefore no entry simulation with all the controls and actions on the fields. It is a direct transfer in the table in the database. The supervisor automatically processes the creation and the modification of the records, for the principal table.

Special import

The special import template is reduced therefore more open, but containing fewer automatic mechanisms. It does not manage the loading of masks, the entry simulation and the update transaction. The processes are written in the specific labels then if required in the $ACTION label for the process associated with the import. It is possible to create special imports for the templates with single, grid or combined OBJects. They are not authorised on the templates without OBJect. The special import is either specific/custom or standard. However, on a standard import, there is still the possibility to add the custom/specific elements by the action IMPORT ; For technical reasons, this action is then to be developed, in the specific/custom process of the OBJect.

The Actions

The standard or specific process described by the label $ACTION to write in the following fashion( where XXXXXX is the event code ) : 

$ ACTION
Case ACTION
   When "XXXXXX" : Gosub XXXXXX
   When default
Endcase
Return

Each event is identified by an alphanumeric code contained in the ACTION variable. If there is no process for the event, the functioning of the function will not be impeded by it. It is in the sub-programme $ACTION, that it is pointed to the added label. Within the "ACTION case " syntax is used to specify that as many lines as events are to be completed. The $ACTION is called from the supervisor process by GOSUB ; this therefore makes it possible to use the local variables from the supervisor process. 

Attached to this is the list of actions. Next the detailed description of these actions is found. Described here is the calling context for the OBJective of these actions.

Add the specific/custom actions to the standard

By, default, for a single event, the specific/custom action is called before the standard action.

It can cancel and replace the standard action if it sets the variable GPEto the value 1. 

To execute the standard action with the specific/custom action, copy the standard process in the specific/custom action, then add the specific/custom process and finally set the variable GPE to the value 1. Example :

Supervisor process
GPE=0
Gosub  ACTION  From  trait_std              ( call to the standard )
If GPE=0
   Gosub  ACTION  From  trait_spé.            ( call to the specific/custom process )
Endif

Specific/custom process
$ ACTION
Case ACTION
   When "OUVRE" : Gosub OUVRE
   When default
Endcase
Return

$OUVRE
...                                                                ( specific/custom action OUVRE )
GPE = 1                                                     (no call to the standard following the specific/custom)
Return

---