Tables

This function is used to create and modify the tables in the database, by describing their characteristics in the data dictionary for the folder. The confirmation of this description is then used to create the table in the database or to modify the characteristics.

The management of the tables is used to define the list of the tables in the database. In fact, activity codes are used to inhibit certain tables and/or certain indexes.

In addition to the structure of the table itself, the following are also defined in this dictionary:

  • the links to other tables (referential integrity links). These links are used by the cancellation utilities, by the import-export functionality and by other tools of this type.
  • the information proposed by default in the screens created from these tables (help key-words, format information, etc.).

A table is identified by its name (uppercase alphanumeric starting with a letter), and it possesses an abbreviation. The creation of new tables during the localization/customization phase assumes that the name starts with one of the letters X,Y or Z. The name and abbreviation must be unique within the database (no two tables can exist with the same name, which is logical and the same goes for the abbreviation: this last restriction is not valid for the screens).

A table can then be manages with the help of an object, on the condition that the necessary screens are created.

Warning:
It is not possible to add fields, specific or vertical characteristics on tables of type "system" or "dictionary". The specific is not maintained upon folder validation or migration.

Prerequisite

See also Refer to documentation Implementation

Screen management

The definition of a view is done using three tabs: a query definition tab, the field definition tab and the key definition tab.

Tab General

Located in this tab is the general information relative to the table and its management.

Tab Fields

This tab is used to define all the fields of the table in a drop-down menu.

In each table, it is possible to use fields whose name is standardized and which will automatically be updated if they exist by object management. The fields are the following:

 CREDAT and UPDDAT are respectively the creation and last update dates.

 CRETIM and UPDTIM are respectively the creation and last update times.

 CREUSR and UPDUSR are the user codes who carried out respectively the record creation and its last update.

 EXPNUM is a sequential number used to date the records with respect to the import/export module (that makes it possible to only export that which has been updated since the last export).

A sixth field can also be inserted in each table. This field is called ENAFLG and it corresponds to an active/inactive flag. If the table in question is managed by an object and that a data type is associated with this fields, the following controls will be made of the fields of this type:

 the standard selection window for the object called by the selection key will automatically filter inactive records.

 an error message will prevent the direct entry by its inactive key code.

This is of course not valid for the management of the object itself (if not, it would not be possible to reactivate the records rendered temporarily inactive).

Tab Index

This tab is used to define the different indexes defined in the table.

Tab Audit

This tab is used to create the setups allowing it to then log by means of database triggers generated automatically, the insertions, deletions and modifications carried out on a table, by storing, if required, the values before and after in specific fields. Any record modification is logged provided one of the field conditions is verifies.  This trace is stored in two specific tables (AUDITH and AUDITL). It can be simply consulted, or give rise to automated notifications, by means of the Workflow.

The main principle is as follows:

  • Provided at least one audit flag (creation, modification, deletion) is checked, each operation of this type creates a line in the AUDITH table. This is made without considering that the fields are logged and the corresponding modifications are made.
  • As soon as the fields are listed in the field grid, any modification of the field value respecting the given condition triggers the creation of a line in AUDITL.

The "trigger" method makes it possible to log operations even if they are carried out by a program other than adonix. The information in this tab is taken into account by revalidating the table: the triggeres are automatically created and/or modified at the same time.

The SUBTRIGGER processing contains the trigger description depending on the database. The SPETRIGGER processing is dedicated to the specific in order to customize their description.

The information in this tab is considered as part of the setups. The standard does not supply any audit setup. It is not necessary to safeguard by activity code X, Y or Z any modification made in this tab. 

The audit is globally conditioned by the AUDIT activity code.

Following cannot be audited:

  • the audit tables themselves
  • the fields of type clob and blob
  • the fields whose data type is AXX

The results of the audit can be viewed using following functions:

Constraints to respect

There are constraints when creating a table. The limits are the following:

concerning the key:
  • limited to 15 indexes at a maximum.
  • limited to 16 fields maximum by index.
  • limited to 250 characters maximum by index.
concerning the record:
  • Under SQL, the limit is 8,060 bytes.
    Under Oracle, there is no limit; but under Adonix, the limit has been fixed to 32K
  • limit of 255 fields per table
  • limit of 512 columns ( field1*dimension1 + field2*dimension2 + ... + fieldN*dimensionN )
  • limit to either a blob or clob type field of any size, or to several fields, but in this case the total size of the table is limited to 64 Kb. 
number of open tables:
  • limit of 255 tables.

Reports

By default, the following reports are associated with this function :

  DICOX3 : Table dictionary

  ATABLIST : List of tables

This can be changed using a different setup.

Specific Buttons

Validation

This function is used to create or to update the table in the database from the dictionary. If the table does not exist, it is created empty of data. If it exists, the table structure is updated conforming to the new description given in the dictionary (the new fields are added, the deleted fields are removed, the fields whose structure or dimension has changed are recopied: the records are of course conserved in the table). It is possible to force the validation: a complete revalidation of the data and indexes. If this option is not specified and if the table structure is not changed, only the indexes will be recreated.

It may also be useful to give default values to the fields in the table for existing records: this is done using the button  button whose functioning is described below.

Process

Is used to create a temporary processing, named WWINIXXX, where XXX is the table abbreviation, which will be executed after the table validation (if it already exists), in order to make it possible to give default values to the fields of existing records. A default processing is proposed when this button is used and it is then possible to add instructions to it.

This processing is made up of 3 labels that are:

 $OUVRE - this is executed at the start before the start of the update transaction, and which must as a minimum open the table that is to be validated (and possibly others).

 $DEFAULT - this is executed after the start of the transaction but before the record read (at least one Default File instruction needs to be inserted so that the default table becomes the table to be updated).

 $INIZON - this is executed for each record, just before they are rewritten. It is therefore in this sub-program that the assignment instructions for the fields in the table can be written.

In this way, for example, if a numeric field MYFIELD is added to the table, a field that should take the value of the OTHFIELD field that exists already in the table, increased by 1, then the following is added in the line processing.

           MYFIELD = OTHFIELD + 1

Warning:
The functioning of this processing is different to that carried out by previous ADONIX versions (for example those used by ADONIX ENTERPRISE version 2 and 3). Indeed, the processing is executed when the structure modification phase is finished. In this way if the XXX field is renamed by calling YYY, it is necessary to carryout this operation over 2 steps, by firstly saving the two fields in the database and then carrying out the assignment YYY=XXX in the initialization processing. It is then possible to delete the XXX field. If an attempt is made to carry this out in a single stage, the processing fails and causes an error (the XX field has become non-existent). It thus possible to loose its value.

________________________________________________________________________________________________________