Data modeling involves organizing business data to fit the needs of business processes by designing physical models that house the data. You can use Axional Studio dictionary to define your database physical model and extend it by adding additional metadata that will be used by application.

# 1 Data definition (DDL)

The system uses the data model to generate database tables for storing the business data. The structure of your data model depends on how you define database tables. These tables defined in the dictionary do not exist in the database until they are deployed.

Whenever the structure of the table (wic_table_object) is modified in the dictionary, these modifications have to be registered in the conversion log (wic_change_log) one by one. This way, when a new compilation is performed, the system can contrasts differences between the table definition in the dictionary and the structure of the table contained in the database.

In addition, each table can have one initial data object (wic_table_object_data) that will feed the table with data as soon as it is compiled into the database.

## 1.1 Table definition

The first elements in DDL definition are tables (wic_table_object). Tables are fundamental objects of a database because it is where all the information or data is preserved.

Dictionary / Physical / Tables

### 1.1.1 Description

Tables are database objects that are structured to contain data in the database. In tables, data is organized according to a row and column format, similar to a spreadsheet. Each row represents a unique record and each column a field within the record. For example, in a table that contains the customer's data of a company there can be a row for each customer and different columns in which appear details, such as the customer's number, name, address and phone number.

Tables are uniquely named within a database.

• Table name*: unique identifier of the table. This must coincide with the name included in the table syntax.
• Order*: usually 0, this value shall only be used if there is a conflict for the system to establish indexes hierarchies. This process is usually automatic and doesn't need the value to be modified.
• Locked: the table has been defined in the dictionary, but it is not going to be deployed into the database. Typically used when table definition it's not yet complete. Only who locked the table can unlock it again.

### 1.1.2 Table syntax

With the table syntax we can define the table structure, indexes and constraints.

• In the table structure each row represents a unique record and each column a field within the record. When defining a table, we need to specify the type of data associated with each column like numbers, strings, temporal data, etc.
• In the definition of a table several FOREIGN KEY clauses may appear, as many as external keys have the table. However, there can only be one primary key, although this primary key can consist of several attributes.
• Constraints are imposed to ensure that the data meets a set of predefined conditions for each table. These restrictions help to achieve reference integrity: all references within a BD are valid and all restrictions have been met.

Table syntax accepts both native SQL and XML syntax. We recommend tables to be created in XML, as this will allow the dictionary to transform the statements to various database engines (Informix, Oracle, Postgres, SQLServer, etc.). Direct SQL statements can be used, but will not be converted to other database formats. For further information on Tables syntax see Languages/Reference/XSQL/DDL/Table.

### 1.1.3 Table compilation

It must be taken into account that once a table has been defined and catalogued in the dictionary, it is mandatory to compile it in order that it exists in the database physical model.

This process is executed by the Deployment object, explained later in this section. This process of table compilation must be executed selecting these options in query screen:

• Type: table
• Action: create

## 1.2 Initial data

When a table requires initial data, they have to be defined in the wic_table_object_data, which has to be accessed by the DATA tab of the desired TABLE.

Dictionary / Physical / Tables

### 1.2.1 Description

The initial data is data that you need on a new system for it to be functional. In many cases, before starting to use a database, it is very useful that it already contains tables with useful data for business logic: for example a table of currencies, since these do not usually change and are essential to define the type of currency in each commercial transaction.

The example bellow shows the initial data form to feed the table customers with initial data:

• Order execution*: it indicates the order in which one table of the system will be fed with data in relation to others that are also deployed with initial data. Rarely used.
• Delimiter*: indicates the type of separation between the columns in the table data, normally pipe because it is the less frequently used in the database data.
• Date format*: indicates which format the dates will have in the database once the table is deployed, regardless of the way they are written on this form.
• Decimal separator*: indicates whether the decimal separator in the database will be a colon or semicolon, regardless of how they are written on this form.
• Columns: indicates which columns of the table are going to be fed with data. If the indicated columns are not fed, data feed will not take place. Use a comma to separate column names.

### 1.2.2 Data compilation

Once the initial data has been defined and created in the dictionary, it is mandatory to compile it in order that it exists in the database physical model.

The process is executed by the Deployment object, explained later in this section. Data compilation must be executed selecting these options in query screen:

• Type: table upload
• Action: create

After the compilation takes place, the screen shows a report with the process result:

#### IMPORTANT

To deploy a table with initial data it is compulsory that, if the table already exists in the database, has no data on it. Otherwise the feeding with initial data will not take place.

## 1.3 Conversions

The conversion log table (wic_change_log object) is the repository of evolutionary changes made to database structures. Use this option to perform modifications on existing structures.

Dictionary / Physical / Conversions / Conversions

### 1.3.1 Description

The physical data dictionary, in addition to containing the physical definitions of the tables of the operating database and a history of changes to these definitions, can also store the different SQL statements of modification. These statements, when executed, will update the tables to the most recent versions available.

Modifying the physical database involves risks and should not be done without sufficient experience. For this reason, and to protect the integrity of the conversion logs, the application does not allow deletion.

• Table*: reference table to which evolutionary conversions will be applied. This name will be also used within the SQL statements.
• Action*: the value of this drop-down explains the system what to do if an error occurs during the execution of the SQL script. You can choose between two actions:
• Stop: indicates if an error occurs in any of the sentences in the block. The next time that the update procedure is executed, it will continue with the same update block.
• Continue: indicates that if an error occurs in a block statement continue with the next block statement. This option should only be selected when all SQL statements perform tasks that do not compromise the structure or content of the tables, that is, they carry out modifications of referential integrity restrictions (primary keys, foreign keys and alternative keys) or control restrictions (default values, null values, validations).
• Locked: lock/unlock conversion log. Only the user who has locked the record has permission to edit it. Until the user who has locked the record does not unlock it, no other user can make changes or delete the selected record
• Always: indicator that forces the auto-upgrade process to unconditionally execute the block of SQL statements contained in the register. By default, this indicator should not be activated. It should always be activated in the following cases:
1. Renaming a table.
2. When no SQL statement makes structure or content changes, that is, they only make changes to restriction rules: indexes, controls, primary keys or foreign keys.
• Message*: brief explanatory comment about the purpose of the conversion. This message will be displayed in the ws-dbschema utility when the system is processing the change block.
• SQL Statement*: in this text field the conversion is introduced, that is, a set of SQL statements that implies a table update.
• Project and notes: the project option allows linking this conversion log to one of the open projects from the wic_dev_projects table on dictionary.
• Documentation of the conversion: information regarding the reason for the conversion. The combination of this documentation associated with each table over time will give us the total evolution of each structure throughout its useful life.

### 1.3.2 Conversion compilation

Although this process is executed by the Deployment object, it is highly recommended to always complete the following procedure to prevent and detect errors:

1. Edit the table model. Access the table schema through the physical dictionary and make the relevant modifications. Remember to add the appropriate comments and save modifications.
2. Create the conversion register. Access the physical dictionary conversion form and create a record that matches the modification made in the table. IMPORTANT: remember to correctly select the Always indicator according to the modification content.
3. Check object status. Access the compile model (dll) query of the deployment menu. Status must be executed selecting this option in query screen:
• Database: database name.
• Action: status.
• Type: all/table/index/check.
• Pattern: table name or pattern.
Press execute button: as a result, the system reports the differences by comparing database table with the new table model. This report includes a recommended solution.
4. Execute the conversion register through the compilation option. Conversion compilation must be executed selecting this option in query screen:
• Database: current database or all.

#### IMPORTANT

When the upgrade action is selected, all fields except Database in the query are invalidated and all non blocked conversions will be executed.

If the procedure was successful, a report should confirm the success of the compilation process.

5. Check object status. As the procedure run correctly, the report should confirm that there are no differences between the model and the database.

#### Conversion Compilation Example

The video below shows as an example of conversion the addition of a new column called 'nickname' to the existing table 'customer' of the database, following the recommended procedure.

## 1.4 Status and maintenance

This process allows the management of the physical model of the chosen database. The databases shown are those whose dictionary is the current connection database and to which you have access.

### 1.4.1 Deployment object

It is very important to keep in mind that once a table has been defined and created in the dictionary, it is mandatory to compile it so that it exists in the database.

Deployment / Compile model (ddl)
• Data base*: allows to select a database where to compile or all databases of which it is the dictionary
• Type*: determines the type of element to be compiled:
• All: all objects
• Table: the entire table/s
• Index: only the indexes of selected tables
• Table load: initial data of selected tables
• Check: only the checks of selected tables
• Action*:
• Create: creation of the physical model.
• Drop: removes elements from the physical model.
• Status: information on the current state of the physical model by comparison with the cataloged model.
• Upgrade: updates of the physical model with the structure changes cataloged in the conversion.
• Pattern*: use this option to easily select desired elements by name. The percent symbol (%) involves all names.

# 2 Data decoration

The data decoration controls how the user visualizes the data without interfering with the way in which they are stored. This transformation facilitates user understanding For example, we can visualize a telephone number separated by spaces, although in the database it is stored without spaces.

## 2.1 Attributes

Based on the attribute definition (wic_jdic_colattr), it can configure the data entry in the system. Attributes determine how fields behave in a form or a report, with a variety of options determining behaviors and states. The attributes allow to define, for a given column of the catalog, properties such as field enabling, visibility, nullability, default values, formats and validation lists.

The attribute configuration does not alter the way data is stored, which is controlled by the type of data in the field and other properties.

Dictionary / Physical / Attributes / Attributes

### 2.1.1 Description

The attribute dictionary allows to define for each column of a database catalog a set of functional properties, which will be taken into account in objects of type transactional, in the time to insert and/or modify information.

The fact of defining attributes to those fields susceptible to it implies:

• Ease and practicality towards users in the introduction of information.
• Maintain consistency and integrity in the data by avoiding the introduction of non-permissible values.
• In the attributes there is no reference to descriptions, titles or labels, so in this table the language does not make sense. The attributes apply to all languages.

For each pair Table and Column, it is possible to define conditions on the following events:

• Input options
• View options
• Query options

The attributes do not depend on the object, only on column and table.

#### Identification

• Table*: name of the column table that refers to the definition of attributes, which must be previously defined in the table dictionary.
• Column*: column referenced by the definition of attributes to be performed, also previously defined in the columns dictionary.

### 2.1.2 Input Options

The system changes automatically the appearance and behavior during data input. For example, if uppercase for a field is selected, both will be visualized and recorded in uppercase.

#### Default value

This field defines the default value to be used for the field (table column) when inserting or modifying a record. They can be defined in several places of the application:

• Directly in this column
• In the roles governing the groups of default values (See Connection Groups)
• Use a business logic in the application to define a specific default value

The precedence rules for default values are PENDING.

The default value can be a value defined during development or a reserved word (the value is set at run time). The following list shows the reserved words that can be used in forms:

• USER: Returns the User Code of the logged user.
• LANG: Code of the User language.
• COUNTRY: Code of the User country.
• TODAY: Returns the current date from the server.
• CURRENT: Returns the current date & time (hh:mm:ss) from the server.
• TIME: Returns the current time (hh:mm:ss) from the server.
• DBMS: Returns the connected Database name (logical name).
• THIS: Returns the original value of a retrieved record.

The following variable values or functions can be used in the back end logic (Server side):

• crypt(password): Returns an encrypted password. Generates an HEXA code of 40 chars, with 2 seed chars (SALT). The encryption is reversible.
• dcrc -32(file_data): Returns the CRC value (32 bits) of the file associated to a BLOB column type.
• digest(password): Returns an encoded password using the MD5 algorithm with 32 chars. The encoding is irreversible. Used for anonymizing purposes.
• name(file_data): Returns the name of file associated to a BLOB column type. Warning : this function will not work if the file has been assigned directly by the user in the form.
• rows(file_data): Returns the number of rows (records) of the file associated to a BLOB column type. The value is only meaningful for text files.
• size(file_data): Returns the size in bytes of file associated to a BLOB column type.
• type(file_data): Returns the type of file associated to a BLOB column type (See BLOB fields definition).
• height(file_data): Returns the height of the image file associated to a BLOB column type.
• width(file_data): Returns the width of the image file associated to a BLOB column type.

To use these options, a “backend rule” should be selected in the field Default Value Rules.

#### Default value rule

This mandatory field defines the rules for applying the default value. If Null/Always/Only new records/If null Backend (its use is limited to the related reserved words in Default values) /Always Backend (its use is limited to the related reserved words in Default values).

This field defines the rules for applying the default value. The available rules are:

• If Null: When inserting new records, if the field value is Null, then the system will use the default value defined in “Default value”. When pressing Clear (or Reset) in a form, the fields will be cleared. This rules allows prefilling the field’s content.
• Apply always: When inserting or updating a record, the default value will be used for this field. This option is used for fields that are input disabled
• Apply only for new records: When inserting a new record, the default value will be used for this field. This option will override the business logic of the object (form) and will assign the default value to this field.
• If Null (Backend): It allows the execution of special functions by the backend of the application. Its use is limited to the related reserved words in Default values, for example, name (file_data), type (file_data), size (file_data), etc. When registering, the default value indicated in this table of attributes will be reported as long as a null value is received from the object.
• Apply always (Backend):It allows the execution of special functions by the backend of the application. Its use is limited to the related reserved words in Default values, for example, name (file_data), type (file_data), size (file_data), dcrc-32 (field_name), crypt (field_name), etc. The default values will always be analyzed, that is, regardless of additions or modifications.

#### Selection Control

When an include has been established as an attribute of the column, it is necessary to indicate the typology of the informed include, since depending on the type of include the way of entering the data in the column is different. For further information about includes, consult Selection Controls (Includes).

• Checkbox: to set the value, a checkbox will be shown. It is a binary selection (true-false, 0-1, Yes-No).
• Switch: to set the value, a switch to enable or disable options will be shown. It is a binary selection (true-false, 0-1, Yes-No). Instead of using a "checkbox" its appearance correspond to a switch.

#### Only binary options

It can be used only for binary options like "Yes/No", "true/false"...
The operation will be the same as with checkbox selection controls.

#### Only binary options

It can be used only for binary options like "Yes/No", "true/false"...
• Radio buttons: to set the value, a predefined set of values will be shown. Each predefined value is displayed as a radio button and only one can be selected.

#### Source values definition

This type of selection controls requires the definition of source values that define the list of predefined values allowed for the column. This list of values can be either specified directly or retrieved by a SQL statement executed at run time.
• Dropdown list: to set the value of the indicated column, a dropdown list with a set of values will be shown. Only one can be selected.
The operation will be the same as with radio buttons selection controls.

#### Source values definition

This type of selection controls requires the definition of source values that define the list of predefined values allowed for the column. This list of values can be either specified directly or retrieved by a SQL statement executed at run time.
• Dropdown list (multiple): to set the value of the indicated column a dropdown list with a set of values will be shown. More than one value can be selected.

#### Source values definition

This type of selection controls requires the definition of source values that define the list of predefined values allowed for the column. This list of values can be either specified directly or retrieved by a SQL statement executed at run time.
• Source selection controls: indicates the include, previously defined.
• Letter case*: if set, then the text will be converted to uppercase or lowercase.

#### Format function

This is the name of the Javascript function to format the content of the field or validate an input field. The Javascript functions used in the column attributes are catalogued in the wic_jdic_jsfuncs table.

Dictionary / Physical / Attributes / Formatting functions

This type of validation should be used in generic situations: place points in an accounting account, verify credit cards, etc. In this example, validation will check in a e-mail input field, if the input text contains @.

The function is invoked in the after for the field, so the field that is invoking the function is passed as a parameter and it must return a string with the value to be placed in the field.

In addition to the Javascript functions that are catalogued in the wic_jdic_jsfuncs table, standard functions that are defined in the dictionary database wic are always included.

In the form we record a code, a description and the body of the function. The body of the function must follow the following specifications:

• Parameter: field HTML object of type INPUT that is invoking the function.
• Return: it must return a string that will be the value to be placed in the field.
• Declaration: the declaration must be FUNCTION_NAME function (field) , where FUNCTION_NAME is the name of the function.
Copy
// =========================================================================
//  TRIM
//  prevents the entry of whitespaces in a field that is intended not null
// =========================================================================
TRIM: function(field)
{
var text = field.value;
// We make sure we have a string, since we use string functions (charAt ...)
text = "" + text;
if (true)
return text.replace(/^\s*|\s*$/g, "") var cChar; var iEnd = text.length - 1; var iStart = 0; cChar = text.charAt(iStart); while ((iStart < iEnd) && ((cChar == "\n") || (cChar == "\r") || (cChar == "\t") || (cChar == " "))) { iStart ++; cChar = text.charAt(iStart); } cChar = text.charAt(iEnd); while ((iEnd >= 0) && ((cChar == "\n") || (cChar == "\r") || (cChar == "\t") || (cChar == " "))) { iEnd --; cChar = text.charAt(iEnd); } if (iStart > iEnd) return ""; else return text.substring(iStart, iEnd + 1); } This FUNCTION_NAME will be the one we will use in defining the attributes. Within the function we will write JavaScript code. If we need to make calls to our own functions, we must catalog this function as one more function. Copy // ========================================================================= // TRIM_QRY_DOWNSHIFT // avoids entering invalid codes in fields that are columns // of database (accents, quotes) // It is used in column attributes wic_jrep_colqry.col_name. // It is different from TRIMSPECIAL_DOWNSHFT ince it accepts '*' to be able to indicate // that you want to query through all the columns. // ========================================================================= TRIM_QRY_DOWNSHIFT: function(field) { var str = field.value.toLowerCase(); var s = new String(str); str = ""; for (var idx = 0; idx < s.length; idx++) { var c = s.charAt(idx); if (!__isLetterOrDigit(c) && c != '_' && c != '$' && c != '#' && c != '@' && c != '*') {
c = '_';
}
str += c;
}
return str;
}

This function uses the __isLetterOrDigit , this function will also be cataloged in our dictionary.

If we can use functions from our JavaScript function library for example setFieldError, getQueryValue, getFieldValue, etc .

These functions defined in wic_jdic_jsfuncs table must follow some specifications.

Standard features:

• DOWNSHIFT: change text to lowercase letters
• UPSHIFT: change text to uppercase letters
• COLOR: color code in hexadecimal format
• HREF: Adds a link that refers to the value of the field. This formatting function is mainly used in fields that contain web addresses.
• PARSEXML: It is used to parse the text of the column in XML so that it validates if the document is well formed. It is useful for when the text is an XML or an HTML. In order for the document to be well-formed it is necessary that all the tags are all closed, that is to say, each one has their correspondence.

1. <tagname></tagname>
2. <tagname />
3. <tagname>

1 and 2 are well-formed but 3 are not. HTML browsers do not give an error when loading a document and it is not well-formed, However, if this text was intended to encapsulate it in an XML document, it would not fail because it is not well-formed.

This function parses the text in XML so that if it cannot be parsed because the document is not well formed, the user is informed with a warning (alert) and sets the field with an error (setFieldError).
A very common example is not to close the tag's br:

<br> not well formed
<br /> it is well formed.

• TRIM: Removes blank spaces and line breaks at the end of the text. Avoids the entry of whitespaces in a field that is intended not to be nullable.
• TRIMSPECIAL: Prevents the entry of invalid codes (accents, quotas).
• TRIMSPECIAL_DOWNSHFT: Prevents the entry of invalid codes (accents, quotes), also converting the text to lowercase letters.
• TRIM_QRY_DOWNSHIFT: Prevents the entry of invalid codes (accents, quotas), also converting the text to lowercase letters. Allows entry of the '*' character.

In addition, there may be special functions defined in the different dictionaries of the ERP application (accounting, management, ...).

Functions for the formatting of fiscal identification numbers (NIF), dates and numbers of bank and account accounts (dictionary wic_icon ):

• ICON_CHECK_CIF: To verify the CIF code.
• ICON_CHECK_FECHA: To verify if the date is within the allowed range.
Consult the parameterization of the allowed date ranges in the cdefcont table.
• ICON_CHECK_IBAN: To verify the IBAN (International Bank Account Number).
• ICON_FORMAT_CUENTA: To adapt the accounting account codes to the mask set in each database.
Check the mask in the cdataemp table.

Functions for formatting of data entered through Android mobile devices:

• DROID_BARCODE: Ability to read barcodes.
• DROID_GPS_LAT: Introduction of the current latitude (median GPS position) as the default value of a field.
• DROID_GPS_LNG: Introduction of the current longitude (median GPS position) as the default value of a field.
• DROID_FOTO: Possibility of making and storing a photo in the field that has the attribute.

An input mask allows you to specify exactly how data should be entered into the database. It's an expression that specifies certain rules about how the data should be formatted as it is entered into the system.

### 2.1.3 View options

#### Display transformation

Display transformation*: select the field attribute option to be displayed between None (default) or one of those listed bellow. Depending on the value and the selected attribute option, the data will be displayed in the way that best fits for a correct understanding.

Type Value Visualization
Time 1.000 00:00:01
90 00:01:30
3.600.000 01:00:00
10.000.000 02:46:40
Milliseconds 1 1ms
100 100ms
10.000 10s 0ms
5.000.000 1h 23m 20s
Nanoseconds 1.000.000 1ms
15.000.000 15ms
1.000.000.000 1000ms
2.147.483.647 2s 147ms
Bytes 8 1 b
1.024 1 KB
1.048.576 1 MB
2.147.483.647 2,00 GB
Percentage 2 2%
44 44%
80 80%
100 100%
Percentage bar 2
44
80
100
Units 11 11,00
222 222,00
3.333 3,33K
888.888.888 888,89M
Currency Euro 1,10 1,10 €
333,30 333,30 €
4.444,40 4,44K €
8.888.888,80 8.89M €
Currency Dolar 1,10 1,10 $333,30 333,30$
4.444,40 4,44K $8.888.888,80 8.89M$

#### Input type

This option controls the Input type, which is mandatory. Select between:

• Auto: normal input, it provides an input box to allow data entry.
• Color: allows the user to select a specific color from a palette by a color picker. The system also verifies format color when it's value is manually entered.
• Multiple: this option provides an input box intended to modify a text column, which will hold a list of values separated by the character pipe "|". The field shows each component as a chip. They are allowed to be added by pressing the ENTER key, and removed via the DELETE key.
• Password: these are text fields where the characters are masked (shown as asterisks or circles). Usually used when a password is needed.

Icon: Icon to be displayed to the left of the column value if the condition (expression) is met or there is no display condition. The icon image must be saved in Images of the SQL object.

#### Translate

Translate*: this indicator is interpreted by the loading and unloading process Manage dictionary contents. The contents registered in the table Idiomatic column contents are the support for the translations (or substitutions) that the application servers will use.

#### Syntax label

Syntax label: this is a helpful mnemonic indicating the syntax that can be used in this field. Syntax labels are defined in the Syntax mnemomic form. For further information about syntax mnemonic, see Syntax descriptions.

### 2.1.4 Query options

• Smart search: if the checkbox is active, during query you can search with or without accents and with or without capital letters.

# 3 Column options

Through this log (wic_jdic_column_options) you can manage different events on specific fields in the table.

Dictionary / Physical / Attributes / Column options

## 3.1 Description

For each pair Table and Column, and optionally an object, it is possible to define conditions on the following events:

• Enable/disable conditions of input fields
• Required fields (mark field as required or non-required)
• Visibility (show or hide the field)
• Reactive values (to automatically calculate dependent value of fields).
Unlike the attributes, it is possible to indicate in which specific object the options here defined will work.

To identify the column options, following data is required:

• Table*: name of the table.
• Column*: name of the column.
• Object: name of the object. Introduces the possibility of defining a parameterization of column options for a specific JRep Object.

It is advisable to document in the NOTES field the logic applied to the definition of these values.

## 3.2 Enable fields input

To enable or disable the input functionality of the field, two types of conditions could be defined:

• Input expression (Server): this expression is executed once at server level when the form is laded.
• Input expression (Client): this type is defined at client level and is evaluated dynamically according to any change in the form values.

It is possible to define criteria to set the field as optional or required, overriding the physical definition of the column on the table.

## 3.4 Field visibility

The condition allows showing or hiding the field. It is executed at the server level. That is why it supports UEL/SQL notation.

## 3.5 Reactive values

It allows calculating the value of a column automatically, depending of the value of other columns of the table. The calculated value is determined by the execution of a UEL Expression. Furthermore, this value is recalculated immediately when any of the values involved in the expression changes.

In this example below, the reactive value equals the sum of values 1 and 2, so the reactive value will change at the time that these values vary.

With the intention of removing any Javascript code from JRep Object used for business logic, this expression is intended to replace the use of the user function setFieldValue, as far as possible.

# 4 Autocomplete and data verification

Autocomplete and data verification is performed by means of Soft References. It is a useful tool when a form contains a field which value must have been previously registered into a database table. For this reason it helps in the selection of the field's value and integrity verification.

Soft References implementation involves two parameterization tables:

1. Helper definition (wic_jdic_softref_help)
Dictionary / Physical / Attributes / Soft references (definition)
2. Field helper relation (wic_jdic_softref_rel)
Dictionary / Physical / Attributes / Soft references (relationship)

## 4.1 Description

Due to its complexity, Soft Reference implementation is detailed in chapter Advanced features, section Soft References .

# 5 Data validations

This option is used to configure through expressions additional validations of field data to those defined in the table.

Dictionary / Physical / Attributes / Data validations

## 5.1 Description

Validation is an automatic check to ensure that the data entered is sensible and feasible. It possible to create a check for each table field when user inserts data in a form or object. For example, you can check that entered data in a field is between an upper and lower acceptable value, within a certain range.

If check is not passed, user is informed by means of a message label and the transaction is not completed.

• Table*: name of the transaction table with fields to be checked.
• Objet: optionally, it can be defined that the verification only affects a table through a specific object.
By the contrary, if value is null, the check will be executed on all the objects with this table.
• Check*: define the check using syntax of Unified Expression Language. For further information see chapter UEL.
• Label*: code of the label message. If the check is not fulfilled, the message defined in this label is displayed. This label must have been previously defined in the Dictionary/Logical/Labels form.

The sample image above shows two types of validation:

• Validation ID 1 (customer): this validation involves a single field (phone). In these cases the validation takes place in the process of insert or update field data.
• Validation ID 2 (studio_clientcheck): this validation involves more than one field, since the value allowed in one field (field_condvalue) depends on the value of another field (field_cond). In these cases validation takes place after saving modifications by means of the Save button.

# 6 Data colorize

The Table Colorizer feature is a grid parameterization for colorizing grid cells depending on its content, generally to emphasize the importance of a cell among a group of cells.

Use it with two purposes:

• The dataset contains numeric values to be classified
• The dataset contains discrete values (numbers or strings) from which we want to obtain the frequency of appearance
Dictionary / Physical / Attributes / Table colorizer

Due to its complexity, data colorize implementation is detailed in chapter Advanced features, section Table Colorizer.

# 7 Binaries definition

Binary fields enable a system file selector, which sends files such as images, documents, PDFs, etc. to the database.

Dictionary / Physical / Attributes / BLOB fields definition

## 7.1 Description

Binary fields are allowed to contain binary data types such as BLOB. The option exists to remove some information from binary fields and place it in other columns of the same entity. This is the case for the fields: name, size, and content type. For this purpose, the attribute functions NAME(), SIZE() or TYPE() are required for their related columns.

This way the system knows if the size exists through the size column. By means of the type and name, the system can succesfully download the file according to its extension. If the file does not exist or is incorrectly defined, the Alternative file (nocfile)will be used instead.

In order for the system to automatically report the name, size and content type fields of the blob file, it is necessary to assign a function in the default value field of the attribute form. The group of special functions related to blob files that is processed in the backend are:

• name (file_data) : returns the name of the file registered in a column of type BLOB. This function will only be effective if the file name has not been previously assigned from the front by the user.
• type (file_data) : returns the type of the file registered in a column of type BLOB.
• size (file_data): returns the size in bytes of the file registered in a column of type BLOB.
• height (file_data): returns the height in pixels of the file registered in a column of type BLOB.
• width (file_data): returns the width in pixels of the file registered in a column of type BLOB.

In the example, the field img_size from the table cp_artits will automatically input the size of the img_data, as it has been defined as a default value for this field in the attribute form.

# 8 Descriptions and Internationalization (i18n)

After the physical database model is defined, you can extend it to enrich database model with localized labels, field descriptions, default values, check constraints and so on.

## 8.1 Table information

Dictionary / Logical / Tables

### 8.1.1 Description

Through this option we access the description of the tables catalog of a database model. From it, if the user has the required authorizations, it is possible to create, delete or modify such descriptions.

The dictionary of tables allows us to define the descriptions of each of the database model tables described, as well as a general description of their functional meaning.

Likewise, it is also possible to access to consult attached information to each of the registered tables:
• To the dictionary of columns for reference on the columns or fields that form the table structure.
• To the register of attributes of the columns or fields belonging to the table.
• To the register of references or integrity relations that the table may have been defined.

As an additional functionality, it is possible to search for tables that in their general information contain a certain string of characters.

• Table*: when the table to register physically exists in the database, this will be the physical name of the database. If it were a virtual table, its name is at the user's discretion. Usually, the criterion to follow is to define a generic table for those alias fields that are generic for the entire application, and for those that are specific to a specific area of the application, a specific virtual table is defined for that area. In any case, it would be convenient for these virtual tables to have a common pattern in terms of their coding, since this would facilitate their location and identification.

It should be borne in mind that if the system detects in the table name some character of the type: ¡!""#$%&'´()*+,-.¨·/:;<=>¿?^@|\\[{} , the system will replace it with a _ (underline), since these characters are not supported as valid for the name of a table. • Language*: language in which they are expressed, both descriptions and information regarding the table. When the system connection users are defined through the configuration database (wic_conf), among other data, the language in which the application is to be used and operated is indicated. Depending on the user and language indicated, you will use the information in the tables corresponding to that language. • Verified: it specifies whether an expert or translator has checked the text. Never mind the current status, there is no automatic process that will affect it. • Tag name: short description. • Description: normal description of the table, that will be the one usually reflected in the help of the application. • General data: this will be where the meaning and properties of the table will be described in detail in terms of their functionalities, relationships, specifications, etc. This information is important for the application users in the sense of being able to know in depth the possibilities of each table, as well as the aspects to consider in each one of them. Therefore, the more explicit this information is, the more facilities will be granted to the user to know and understand the application. ## 8.2 Column information Menu path: Dictionary / Logical / Columns Through this option we access the catalog description of database model columns. From it, if the user has the required authorizations, it is possible to create, delete or modify such descriptions. Column dictionary allows us to define descriptions and information related to columns associated to a database catalog as well as a description of features and properties of each of them. Likewise, it is possible to access to consult information attached to the table to which columns belong: • To the table dictionary for reference on its definition. • To the register of attributes of table columns. • To the register of references or integrity relations of table columns. • Table: name of the table to which the column belongs, that must be previously defined in the table dictionary for the same language in which you want to express the column information. #### REMARK It should be borne in mind that when the system detects in the column name some character of the type: ¡!""#$%&'´()*+,-.¨·/:;<=>¿?^@|\\[{} , the system will replace it with an _ (underline) , since these characters are not accepted as valid for the name of a column.

• Language: language in which they are expressed, both descriptions and information regarding the column. When the system connection users are defined through the configuration database ( wic_conf ), among other data, the language in which the application will be used and managed is indicated. Depending on the user and language indicated, you will use the information in the columns corresponding to that language.
• Verified: It specifies whether the text has been checked by an expert or translator. Never mind the current status, no automatic process will affect it.
• Country:
• XSQL expression: this check box must be activated when you want to enter XSQL code as a label. This code must be reported in the Label field. This way, when you use the column in a form, then you get the result label of executing an SQL query, for example.
• Column*: when the column to register physically exists in the database, this will be the physical name of the database. If it is a column of a virtual table, its name must be the one specified in the definition of the objects in which it will be used.

#### REMARK

It should be borne in mind that when the system detects in the column name some character of the type: ¡!""#$%&'´()*+,-.¨·/:;<=>¿?^@|\\[{}, the system will replace it with an _ (underline), since these characters are not accepted as valid for the name of a column. • Label: this mnemonic description of the column represents a type of abbreviated description, which will be the one that is presented as a title in all those objects in which it is found as a column or output field. If it is necessary to put a line break, for example, if the tag contains more than one word and a line break is desired, it is only supported for it <br/>. Expression Evaluation Example Description <xsql-text><eval-date d='-1'>$FECINI</eval-date></xsql-text> The label <xsql-text> allows the evaluation of XSQL expressions at runtime, producing the corresponding code according to the database engine. Access the programming documentation XSQL Script to expand the information.
(select coment from cejercic where numero = $ejerci-1) Simple SQL statement whose syntax is common to all engines. DATE($fecfin)+$diacad SQL function common to all engines. • Description: Description of the column, which is very important because it will be reflected by the system, among others, in the following cases: • Help . On all automatic online help pages generated by the system. • Comment . In those objects of type transactional it will function as a comment of the fields that the object contains. • Information . When a HTML page of the result of an object is obtained, it is used as additional information to the title of the columns that the object contains. • General data: This will be where the meaning and properties of the column will be described in detail in terms of their functionalities, relationships, specifications, etc. This information is important for application user in the sense of being able to know in depth the possibilities of each column, as well as the aspects to consider in each of them. Therefore, the more explicit this information is, the more facilities will be granted to the user when it comes to understanding and knowing the application. ## 8.3 Selection Controls (Includes) Through this option you can access the definition of includes or lists. These can be assigned as possible values to the columns, through the parameterization of their attributes, or to the object query variables. From this option, if the user has the necessary permissions, they can create, delete or modify these definitions. Menu path: Dictionary / Logical / Includes ### 8.3.1 Description An include is used by assigning it as attribute of a column so that it is a reusable object. You could also assign includes as possible values of a query variable associated with an object. The system loads the dictionary includes for the user's language. The includes that do not depend on the language (for example, an include of type SELECT that obtains the company codes of the application) are registered only once. To identify the column options, following data is required: • Code*: name of the include. It is recommended to adopt a coding criteria and methodology in order to reuse the includes in all those fields of the database that are functionally equivalent. • Value*: value of the data. The value of the data will depend on the type of include to be defined. • Order*: order in which the system will present the list of defined values. This indicated order will be valid as long as the include is of type Check or List. Because if it is an include of Select types, the order will be the one established in the SQL statement reported, simply indicating here the value 0. • Icon: adds an image to the included, for an easy identification of the selected option. See icon section. #### Remarks • If the include is of type list, if there is an element that in database is null in the Value field, the keyword NULL must be reported. • If an SQL query is used to obtain the list, in the Value field the keyword SELECT must be informed. • The SQL statements of SQL query and Default value for the SQL query can be written in XML grammar. • Default value for the SQL query can only be reported if the include obtains the list of values using an SQL query. Depending on how the column attribute to use the include is defined, and whether it specifies values or an SQL query, or if it has a reference column, different functionalities can be obtained. More specifically, we can have column attributes with the following types of include: • None (no include) • Checkbox • Radio button • Select one • Select multiple #### Include definition • For the same code, multiple records that specify the different values and their descriptions are stored. • A single record for the include code specifying value 'SELECT' and the corresponding query. • Include with value 'SELECT' specifying reference column and dynamic condition. ### 8.3.2 ICON include Icon to be displayed to the left of the column value if the condition (expression) is met or there is no display condition. The icon image must be saved in Images of the Object SQL. The expression is written in javascript format. For example: #### Expression Examples Evaluate the locale column to compare with the value es Copy '#locale'=='es' Evaluate the locale column to compare with the value es and also that the tabname column is different from mytable Copy '#locale'=='es' && '#tabname'!='mytable' ### 8.3.3 SQL Query include and Default Value It may be necessary to obtain the values from the include list of a table in the database, in this case you must indicate in this field the SQL statement to perform the SQL Query or the call to an XSQL-Script. This query is possible to be written in XML grammar. If an SQL Query or an XSQL-Script call is used to obtain the list, the SELECT keyword must be reported in the Value field. #### Example SQL query to get the list of values For example, to show the list of possible options for the sistem field of the capuntes table, you get the list of the csistema table SELECT code. Copy SELECT codigo, nomsis FROM csistema ORDER BY codigo Only when a query SQL statement is used to obtain the available data from the include, it is possible to report the "Default value for the SQL query" field. There is also the possibility of obtaining the data by making a call to an XSQL-Script. The XSQL-Scripthas to return a ResultSet or virtual table. An array can be converted to ResultSet using the <array.toResultSet> function. #### Execution example of an XSQL-Script to obtain the list of values For example, to obtain the list of user-accessible databases, the <system.user.getDatabases /> tag can be used and as this function returns an array, via <array.toResultSet> a ResultSet is returned. Copy <call> <![CDATA[ <xsql-script> <body> <return> <array.toResultSet> <system.user.getDatabases xdict='$DBMS' />
</array.toResultSet>
</return>
</body>
</xsql-script>
]]>
</call>

#### Default Value

If the include is a SELECT to the database, it will show as a result the list of the values obtained when making the query. This field indicates the value that should appear selected in the list.

This default value is obtained through this SQL query. The query must return a single record with a single field. It can be written in XML grammar. The default value of the column attributes that have this include will not be considered, since it will be the value obtained through this query that prevails.

Example to get the default value:

#### Example to get the default value

If the SQL statement has been indicated in the SQL query to obtain the list of values for the sistem field of the capuntes table, the default value would be obtained by the following query (written in XML grammar , being this optional)

Copy
<select>
<columns><nvl>MIN(sistem), 'A'</nvl></columns>
<from table='cdefcont' />
<where>tabname = 'capuntes'</where>
</select>

### 8.3.4 Checkbox (attribute type checkbox)

The includes of type Check are those to use when the values to enter are of the type TRUE-FALSE or  YES NO  , which in the first case are stored in the database as 1 and  0  respectively and in the second as Y and N, depending on the field is a SMALLINT or a CHAR (1).

The checkbox will be activated for the first value of the include according to the order field, and deactivated for the second value.

The presentation of the Y value would be Activated, and for  N   Disabled.

The definition of an include of this type would be the following:

Example include type ChecK
Code Value Order Description
TRUE-FALSE 1 1 Yes
TRUE-FALSE 0 2 No

### 8.3.5 Static list (attribute type select, include with multiple records)

The includes of type List are those to be used when the values to be introduced are several and diverse, such as a field that indicates the status (open, closed, validated, accounted for ...).

An include of this type allows you to display a description that corresponds to the value Internal field in database. For example a field that indicates the state . It could be a char(1) . The correspondence of values could be:

• A: open
• C: closed
• V: validates
• B: accounted for

The form shows a list with the descriptions, which provide the necessary information to the user, but internally the value is managed by the character code ( char (1) ).

The definition of an include of this type would be the following:

Example include type List
Code Value Order Description
status A 0 Open
status C 1 Closed
status V 2 Validated
status B 3 Accounted for

### 8.3.6 Dynamic list by query (attribute type select, only include specifying SELECT value)

Includes type List with SQL query are those that use an SQL query to obtain the data list. In this case no descriptions are reported and the value field indicates the keyword SELECT . Only in this case it is possible to report the default value for the SQL query, which is also obtained via an SQL query.

Both SQL statements (obtaining list of values and default value) can be written in XML.

The definition of an include of this type would be the following:

Example include type List
Code Value Order SQL Query Default value (optional)
sistem SELECT 0 SELECT codigo, nomsis FROM csistema ORDER BY codigo
<select>
<columns><nvl>MIN(sistem), 'A'</nvl></columns>
<from table='cdefcont' />
<where>tabname = 'capuntes'</where>
</select>


## 8.4 Labels

Labels are small descriptions that allow idiomatic translations and can be easily reused.

Dictionary / Logical / Labels

This form allows defining labels in an idiomatic way. These labels can be used during form construction. Labels can be used in:

• Box headers in forms
• Form layouts
• Button titles
• Data validation messages
• Syntax Mnemonics
• Map layers
• Values of ranges

When the connection users to the system are defined through the configuration database ( wic_conf ), among other data, it is defined the language in which the application will be used and managed. The function getDictionaryLbl(String labelID) allows to obtain a label in the user's language of the user's connection to the system. Depending on the user and language indicated, the system will use the description of the labels corresponding to that language.

These are the fields that define a label:

• Language*: select a new language and use this language in Description and Information fields.
• Verified: it specifies whether the text has been checked by an expert or translator.
• Code*: identifier of the label. Repeat this code for each selected language in order to create a new language of the same label.
• Description*: this text will be shown to the user in the objects where labels have been used.
• Information: usually, the documentation implemented here is shown by a floating component or a large fixed component, so that the information can become very extensive, even in the form of a document with sections.

## 8.5 Syntax description

The mnemonic codes are used to identify the syntax applicable to a field. The use of Labels to describe the content of the mnemomic code allows it to be displayed in the user's configured language.

Dictionary / Logical / Syntax mnemotechnic

These are the fields that define a mnemonic:

• Code*: name that identifies the syntax mnemonic code.
• Label*: name of the label that will describe the mnemonic code, visible from the field this mnemotechnic is assigned to. When the users click on the label, the text of the information box defined in label form (if present) will be displayed by a floating component.
• Background color*: background color for the mnemonic label.
• Text color*: text color for the mnemonic label.

## 8.6 Images

This is the repository of images that illustrates the dictionary (including menus) and the SQL objects. These images can be obtained by means of a file or from icons packaged into a font. Icons look like images, but they can be handled as fonts. Due to the color and scalability properties of fonts, it is highly recommended the use of icons rather than images.

Dictionary / Logical / Images

These are the fields that define an image:

• Name*: code that identifies the image.
• Description: brief description of the icon/image.
• Source*: select between the three options depending on the origin of the image.
• File: an image file.
• Font "Awesome": Font Awesome is a huge collection of icons. Access the Font Awesome website and select the desired icon and copy the icon code.
• Font "Material": Material Design Icon is a full suite of official material design icons, created and maintained by Google, for easy scalable vector graphics on websites or desktop. Access the Material Design Icon website and select the desired icon and copy the icon code.
• Glyph (hieroglyphic): when the source is a font, enter here icon code from the website.
• Color: when the source is a font, select here desired color for the icon.

#### IMPORTANT

If no color is selected, the system will display the icon in black or white depending on the darkness/lightness of the background.

• Choose file: when you select this option, standard opening dialog box appears and an image file can be selected. After unloading image, the fields Size, Type, Width and Height will be automatically filled in.

## 8.7 Check constraints description

Dictionary / Logical / Check constraints / Checks descriptions

Through this option you can access the checks dictionary to enter the descriptions associated with the check constrains of a database catalog.

These descriptions will be those shown to users when they insert or modify records in a table, in case that the record to be inserted or modified does not meet the conditions of any of the existing checks.

#### Nomenclature

Usually, the convention for naming check constraint description is c_name of the table_n, being n successive numbers. This way it is easy to locate in which table the constraint has been incorporated.

### 8.7.1 Inactive check constraints

Dictionary / Logical / Check constraints / Checks inactive

Through this option you can access the check constraints register, of which it is desired that the system does not display or warn of possible problems when evaluating the syntax of these checks. The mere fact of registering a check is already sufficient condition so that it is not displayed.

However, registering it does not mean that it cancels its operability and functionality, since it will be its own database the one that denounces the cases in which the conditions of the same are not fulfilled.

## 8.8 Status and maintenance

To improve the consistency of the database, the location options allow you to find and/or modify the incomplete elements of the logical dictionary. It mostly refers to translation tables.

### 8.8.1 Generate dictionary

Dictionary / Logical / Generate dictionary

This procedure allows us to generate the logical tables (wic_jdic_tabdata) and columns (wic_jdic_coldata) dictionaries in the established language of the physical tables in the database that meet the query conditions.

This procedure is of great use when we start defining dictionaries according to the established database. This is because by analyzing its catalog of tables and columns, it generates all dictionary records of the catalog.

The process accesses the systables catalog of the indicated database and obtains the tables that meet the criteria:

• For each table, it checks if it has been created in the wic_jdic_tabdata logical dictionary for the indicated language. If not, the process generates it.
• For each table, it accesses the physical record of columns sycolumns to obtain the columns of the table.
• For each column it checks if it has been defined in wic_jdic_coldata . If not, the process generates it.
• Tables and/or columns that were already cataloged are ignored

This example shows that for the database named 'demo_form", it will be created the table name and columns names in French (if they don't already exists). The name and descriptions will coincide with the name defined in the physical dictionary.

#### Considerations

• Dictionaries will be generated from the physical tables of the established Master database.
• The system will only generate dictionaries for those tables that have not yet been established in that language.
• The generated dictionaries will contain descriptions of tables and columns that will match the name of the table and columns on the physical table. Therefore once they have been generated, they should be rewritten on this information in the correct language.

Once the generating process has finished, the system will display a list of records inserted in the dictionaries.

### 8.8.2 Language translation of contents data

#### Columns (Edit)

This object allows editing translations in the column dictionary, showing two blocks of information with the texts of the two selected languages.

Dictionary / Logical / Language translations of content data / Columns (Edit)
• In general, this resource will be used informing the reference language, usually spanish (es), in the source language and any language from the available list in the destination language.
• The source language and the target language cannot be the same.
• The target language cannot be the reference language.
• Changes may be applied, interchangeably and at the same time, in any of the texts of the two languages.
• The edition of a record will mark it as verified. This allows you to exercise some control over the work pending translation. Extended content columns (wic_jdic_coldata.col_info) do not apply control over the audit indicator.
• The edition in the reference language will deactivate all verification marks on the entries of the remaining languages. This allows alerting that perhaps your translations should be reviewed.
##### Selection of the content to translate

The content selection process allows discriminating the records on which we want to review or translate, according to:

• Review entries pending translation: only records that have never been translated will be selected. Records translated with the verification mark disabled will be excluded.
• Review entries pending translation and verification: records that have never been translated will be selected and also records with an verification mark disabled. This is the default selection method.
• Review everything: all records will be selected (not translated, translated and translated with verification mark disabled).
##### Sequence of automatic modifications on repeated texts

The modification process allows the management of repeated contents. For this purpose, the changes are made in two blocks according to:

• The modification process allows the management of repeated contents: for this purpose, the changes are made in two blocks according to:
1. First proceed to modify the selected record in the three text columns: col_memo, col_desc and col_info. The records will be marked as verified.
2. In the second phase, all records whose contents in columns col_memo and col_desc are coincident are modified, except for the modification on column col_info. The records will be marked as verified.
3. In the third and final phase, all records whose contents in column col_memo are coincident are modified, except for the modification on columns col_desc and col_info. In this phase, only the repetitions in the column col_memo are considered. The records will not be marked as verificate, unless the base record on which we have applied the modification does not have content in the column col_desc: in that case the record will be marked as verified.
• Changes in target language texts: this block of modifications is substantially similar to the block of changes defined for the source language, but with the difference that the change guide to be applied are the records with matching texts in the source language. This cause that sometime the process requires inserts in the wic_jdic_tabdata and/or wic_jdic_coldata tables, for cases of records in the target language without translation.

#### Labels (Edit)

This object allows the translations editing, regardless of the source language and/or the target language.

Dictionary / Logical / Language translations of content data / Labels (Edit)

A source language and a target language must be selected, just like in column editing section. This object shows two blocks of information with the texts of the two selected languages. Remember that the edition on the reference language will deactivate the verification marks on the entries of the rest of languages for this label.

##### Selection of content to translate

The content selection process allows discriminating the records on which we want to review or translate, according to:

1. Review entries pending translation: only records that have never been translated will be selected. Records translated with the verification mark disabled will be excluded.
2. Review entries pending translation and verification: records that have never been translated will be selected and also records with an verification mark disabled. This is the default selection method.
3. Review everything: all records will be selected, these are not translated, translated and translated with verification mark disabled.

#### Idiomatic content of the columns

Dictionary / Logical / Language translations of content data / Idiomatic content of the columns

Through this option you can access the definition of the idiomatic descriptions of column contents, where, if the user has the necessary permissions, you can create, delete or modify these definitions.

It allows applications to display the idiomatic content of certain contents (tables.columns) in the user's language. As a rule, they will be descriptions belonging to configuration and parameterization tables, such as the descriptions of the tax rate tables, methods of collection or payment, workflows, statements, etc.

The contents registered in the table of idiomatic contents of columns are the support for the translations (or substitutions) that the Axional Studio application servers will perform during the generation of HTML, PDF pages, etc.

To facilitate the offline translation and updating tasks of this table, optionally, it has a loading and unloading process based on the process of columns idiomatic content management.

#### IMPORTANT NOTE

The implementers must protect the tables on which there is the possibility of translation or substitution of contents. They should limit the transactional functionality of modification (update) of records to all users who wish to benefit from the ability to view the contents translated into their language.

This process allows the loading and/or downloading of contents through an Excel file to the wic_jdic_coltran idiomatic contents of columns . It is simply a help tool and its remit can be accomplished by any other manual or automatic procedure.

Dictionary / Logical / Language translations of content data / Loading and/or unloading of translations

##### Common input data
• Database: code of the ERP or client database that will facilitate the contents to be translated. The language of these contents is considered the base language of translation and it is implicit in its contents.
• Language: it is the resulting or target language to which we are going to translate, that is, if the base or reference language is Spanish and we want to translate into English, this will be the one we must indicate in this field.
• Action: Load or Unload, see below.
• Excel name: name of the Excel file.
• Pattern: Pattern in LIKE notation to determine the set of tables to process.

Unload: allows you to download the content of texts from the client's database to an Excel file document, which will serve as a working base for translation tasks. The tables for which content will be downloaded must be informed in the table wic_jdic_colattr column attributes table with the Translate flag enabled.

Process:

1. It gets the list of tables.columns for which you want to offer content translation according to the Translate indicator, mentioned above, and limited to the execution Pattern of this process.
2. It connects to the customer database that has been reported, downloads the contents and records them in a temporary table.
3. Add to the temporary table the possible contents already translated in previous loading and unloading processes, which will be obtained from the wic_jdic_coltran idiomatic column of contents.
4. Finally, all the information is downloaded in an Excel document, which can be used as a translation work base for later loading by this same object or any other procedure.

Load: allows you to load the contents of an Excel document on the table of wic_jdic_coltran
idiomatic contents of columns.
Process:

1. Removal of content on the wic_jdic_coltran table, according to:
Copy
<delete table='wic_jdic_coltran'>
<where>
wic_jdic_coltran.ref_dbms = <p_dbms/>       AND
wic_jdic_coltran.tab_name LIKE <p_pattern/> AND
wic_jdic_coltran.lang_dst = <p_lang/>
</where>
</delete>`
2. It loads all the contents of the Excel document on the wic_jdic_coltran table.

#### IMPORTANT NOTE

The record on the table wic_jdic_coltran idiomatic contents of columns allows not to inform the code of the database, so that the content substitution algorithm allows to generalize common translation blocks for several databases. However, the two processes described in this object will deal with the database code column (wic_jdic_coltran.ref_dbms) informed with the code of the selected database.

#### Descriptions of objects (Edits)

Dictionary / Logical / Language translations of content data / Descriptions of objects( Edit)

Through this option you can access the description of the objects of the application, where, if the user have the necessary permissions, they can create, delete or modify these definitions.

Each object shows the definition of the title, the short description and the detailed information in the base language. It can also be defined in several languages (Spanish, Catalan, English, etc...). In this case, it can be modified directly from this form.

#### Edition of the language descriptions of the channels

Dictionary / Logical / Language translations of content data / Edition of the language descriptions of the channels
This functionality will be withdrawn

## 8.9 Consistence

A term that is repeated throughout the application can be translated in different ways by each translator, something that can generate confusion and different interpretations in the reader. The lack of consistency becomes an even greater risk when it comes to a multilingual project.

The following tools facilitate the task of maintaining the linguistic coherence throughout the entire application.

### 8.9.1 Localization

#### Descriptions without translation

This tool facilitates the quick search to find those entities that lack of language translations.

Dictionary / Consistence / Integrity / Dictionary columns not found

From a source language, this tool looks for the different entities that have no translation in the target language. The query options allows you to limit your search to certain entities among:

1. Panels (wic_jmnu_tab)
3. Tables (wic_jdic_tabdata)
4. Columns (wic_jdic_coldata)
5. Includes (wic_jdic_include_locale)
6. Labels (wic_jdic_lbldata)
7. Check descriptions (wic_jdic_chkdata)
8. Objects (wic_jrep_object)
9. Channels (wic_pt_channel_int)
11. Error codes for xsql_scripts (wic_xsql_script_messages)

#### Comparison of languages

Dictionary / Consistence / Localization / Comparison of languages

This option allows to improve the quality of translations by comparing the same terms, which guarantees consistency in translations within a dictionary.

From a source language, this tools looks for the existing translation in two more selected languages. The query options allows you to limit your search to certain entities among:

1. Panels (wic_jmnu_tab)
3. Tables (wic_jdic_tabdata)
4. Columns (wic_jdic_coldata)
5. Objects (wic_jrep_object_info)
7. Labels (wic_jdic_lbldata)
8. Functional groups of objects and panels (wic_jrep_roles)
9. Includes (wic_jdic_include_locale)
10. Error codes of xsql_script (wic_xsql_script_messages)

#### Test of phrases replacement

This report performs a test (simulation) with the results of replacing sentences in dictionaries.

Dictionary / Consistence / Localization / Test of phrases replacement

For example, suppose we want to replace in the dictionaries for the Portuguese language the text Aquisições with the text Compras, three automatic substitutions will be used anywhere in the text, according to:

1. The texts as they were introduced: Aquisiçõeswill be replaced by Compras.
2. Lowercase texts: aquisições will be replaced by compras.
3. Uppercase texts:AQUISIÇÕES will be replaced by COMPRAS.

Dictionaries analyzed

1. Panels (wic_jmnu_tab)
3. Tables (wic_jdic_tabdata)
4. Columns (wic_jdic_coldata)
5. Objects (wic_jrep_object_info)
7. Labels (wic_jdic_lbldata)
8. Includes (wic_jdic_include_locale)

Possible conflict with singular and plural words

Singular word substitutions can cause problems about their corresponding plural words. Let's take the following example:

##### Example
English Portuguese
Local office Delegação
Local offices Delegações

A widespread error has been detected in Portuguese dictionaries, Local Office, in Portuguese was incorrectly translated by Delegaçõe.

By correcting this word Delegaçõe by Delegação words will be spoiled in the plural, changing Delegações by Delegaçãos. As the plural of Local Offices in Portuguese must be Delegações, we will have to apply a second substitution according to:

1. First substitution: Delegaçõe by Delegação. This substitution will alter the plural words by changing them from Delegações to Delegaçãos, that is, to correct it you will have to apply the second substitution.
2. Second substitution: Delegaçãos by Delegações

#### Replacement of phrases

This object will execute a process for replacing one sentence with another in dictionaries. The way this replacement is performed is the same described in the previous section Test phrase replacement in dictionaries.

#### Warning

This process is irreversible, that is, once executed it may not be possible to reset the original values. To first verify the impact of the changes, perform the Test phrase replacement in dictionaries.

#### Object title generation

This process generates a complete dictionary of titles and descriptions of SQL objects in a given language. Entries generated are those which do not exist for that language compared to the central SQL object dictionary.

#### Atention

A dictionary of titles and descriptions of SQL object should not be generated for the language in which object descriptions are. This would mean that default descriptions would cease to be valid, for language titles prevail over default titles.

#### TO DO

This section is incomplete and will be concluded as soon as possible.
##### Copy lang contents from active dictionary to another

This process copies the language content of the active dictionary to the selected dictionary.

It is required that the structures of the language location tables in both dictionaries are identical.