To define an object it is necessary to access the dictionary of the application and select through the menu this option:

This takes you to the Object Definition Form:

This form is common for different objects, although not all options are valid for all object types. Fields marked with an asterisk (*) are mandatory.

1. TABS: tabs allow you to navigate between forms, all related to object design. The current view corresponds to the highlighted tab Object.
   • Common tabs: Input, Variables, Output, Links, Languages, Metaquery and Alias.
   • Exclusive tabs for reports: Report Styles, Report tabs, Groups and Headers.
   • Exclusive tabs for forms: Form and TX Manager.
2. IDENTIFICATION:
   • Object name*: it must be the unique identifier. Use conventional syntax, with lowercase letters and underscore between separate words. As usual, it is preferable to give a meaningful name to the object.
   • Tag name: it corresponds to the name that will be displayed in the object's tab. Capitalize the first letter of the tag name.
   • Title*: it is the text that appears in the object header. Use capital letters.
3. ADDITIONAL INFO:
   • Group*: this field corresponds to the functional groups of objects and panels. It serves to assign role permissions through the wic_conf, assign database objects and menu panels.
   • Render type*: there are two render modes for an object as a way to design forms: singlerow and multirow. The singlerow render mode displays a single record from the statement at once. It is necessary to select forward/backward buttons to display next/previous results. The multirow mode shows all data resulting from the object statements in rows. The last row is used to make simple inputs when data entry is allowed or to edit selected rows. See Form Layout for further information.
   • Execution type*: select between read mutable (special reports with capabilities for data change), read/write (transaction forms), process (makes transactions and performs a report) and not allow background (only for not to run processes in the background).
4. STATUS:
   • Active: if the active box is enabled, then the object can be selected and executed. Deactivate if the object is being design or under revision.
   • Full output: by default the results of a report are paginated in as many pages as necessary. On the contrary, if the option Full output is enabled, all results will be displayed on a single page.
   • Print*: choose between Try Vertical or Always landscape.
5. PERFORMANCE:
   • Forces reload: data is reloaded every time user accesses to any register. Recommended only for objects with a high concurrency of users, since it adversely affects performance.
   • Refresh: time, expressed is seconds, to perform a complete data reload.
6. PERMISSIONS:
   • Reorder: the objects will show the standard options to reorder result set. Have in mind that processes should not allow reordering.
   • Query allowed: the object will show query icon.
7. WEB SERVICES:
   • SOAP: allows accessing the object via this protocol.
8. ORDER BY CRITERIA: it controls the initial order in which the Result Set of the SQL statement is displayed.
9. SQL STATEMENT: SQL statements are used to retrieve data from the database. This would be the data the JRepObject uses to operate. This data is commonly referred to as Result Set or Cursor.
10. THE OBJECT BUTTONS:
    • Replace object:
    • Buffer edition: Axional Studio has the option to edit reports in Buffer mode, just by pressing the Buffer edition button. During the buffer mode, the report can be modified and saved several times without the need to document the delta. Use Buffer revert button to discard changes or Buffer commit button to accept them. After commit is performed, it is mandatory to document delta.

      WARNING

      During the buffer mode edition, user will execute all changes saved when executing the object.

    • Update menu/table description:

As well as information regarding identification and object parameters, it will be also possible to define:

• Information on the object: Information about the content and functions of the object.
• Image: image of an example of the object result.
• Objects to which it is referenced to: ist of objects that are hyperlinked to that given object.

Likewise, it is possible to access to consult and/or describe information attached to objects:

• Register of object output fields.
• Register of the object input fields.
• Register of the object query variables.
• Register of the object hyperlinks.
• Register of the object language descriptions.
• Register of the object groups of headers.
• Register of the object restrictions.
• Register of the object authorizations.

As an additional function, it is also possible to perform the following ones:

• Generating an object in XML format.
• Copying objects to create similar ones or to transfer them to another repository database
• Automatically generating input and output fields for those objects which represent masters; that is, its code is equivalent to a database table name
• Delete an example image associated to an object.

When we talk about databases, a query is a request for data stored in that DB. Queries are a way of searching for and compiling data from one or more tables.

The QBE (Query By Example) provides a simple interface for a user to enter queries. Instead of writing an entire SQL command, the user can just fill in blanks or select items to define the desired query. Each query field represents a field in a table that you want to consult. Usually, entries are only made in query fields for which you want to specify search criteria.

The query fields must be defined through the object instance form wic_obj_base:

The components that define a query field are:

• Order: the order in which the input fields will appear. If the object had query variables associated, the input fields are displayed first, and the variables are displayed afterwards.
• Table: the table where to consult the query.
• Column: name of the column you want to provide the user with the possibility of introducing a selection criterion. As a column name, the character * would be accepted. This would be equivalent to registering as input fields, of all the columns belonging to the indicated table. This option avoids having to register all the columns of the mentioned table.
• Value: allows assigning default values to a query field.
• Not precede: through this indicator we inform the system that when constructing the SQL statement of an object, the column referenced by the record is not preceded by the table name. This functionality is very useful when it comes to establishing and defining links between objects that operate with different tables and with the same columns, since it avoids the obligatory need to use input variables, since setting the "$ 0" clause in the link condition would give an SQL error because the table of the source object would not be found in the SQL statement of the target object.
• Required: Query fields can be marked as required by the Required value indicator (Yes/No). Required fields are questions that must be answered before the form can be submitted. These mandatory fields are easily recognizable as they are indicated by an asterisk The opposite of a required field is an optional field, also called voluntary fields.
• Destination chart: chart on which validate
• Destination column: column on which validate
• Condition: when defining an integrity or validation relationship between tables and columns, there is the possibility of establishing a condition in the selection of the records of the target table.
  This selection condition must be expressed in the form of a SQL statement, a statement that the system will incorporate in the WHERE clause at the time of validation.
  The selection condition can also be dynamic; that is, if, at the time of validation, the validation condition depends on some of the data being entered in the data entry. This circumstance could be established in the selection condition.

When the user enters some selection criteria in the input fields of an object, the system will translate it into SQL language, and will add it to the end of the SQL statement built for the query to the database.

When the object consists of a simple SQL statement, that is, a single SELECT statement intervenes, the object will be executed without any problem.

When the object consists of a complex SQL statement, in which several SELECT instructions are involved, or it consists of a GROUP BY clause, then it will have to be indicated, using the AND $ 0 operator, the appropriate place in the SQL statement where we want the system to add the syntax of the selection criteria entered by the user.

Name of the table and column you want to provide the user with the possibility of introducing a selection criterion.

The column reported here, for the indicated table, should be registered in the wic_jdic_coldata column dictionary on the system.

Query fields allow specifying a default value by specifying one value on the Value attribute at Query Fields entity (wic_obj_inputqry.qry_defvalue). Although the user can modify this default value before executing the query, its use is recommended in those cases where it is the most common query value.

When defined, the QBE page will initially display the input field with the corresponding value.

The final goal of QBE page is to generate an SQL clause that will be used in a server side statement as a filter condition to limit the number of rows to be displayed in a view. The following section explains the process of conversion from the introduced QBE params into the mentioned SQL clause.

The tables below contain the translation between QBE expressions into the corresponding SQL clause.

Common clauses

Type	QBE Param	QBE Value	SQL clause
Equal	Firts Name	John	Copy user.first_name = 'John'
Not equal	Firts Name	!=John	Copy user.first_name != 'John'
Is in List	Firts Name	John|Mary	Copy user.first_name IN ('John', 'Mary')
Not is in List	Firts Name	!John|Mary	Copy user.first_name NOT IN ('John', 'Mary')
Empty	Firts Name	=	Copy user.first_name IS NULL
Not Empty	Firts Name	!=	Copy user.first_name IS NOT NULL

Character fields

Type	QBE Param	QBE Value	SQL clause
Starts with	Firts Name	J%	Copy user.first_name LIKE 'J%'
Not starts with	Firts Name	!J%	Copy user.first_name NOT LIKE 'J%'
Ends with	Firts Name	%J	Copy user.first_name LIKE '%J'
Not ends with	Firts Name	!J%	Copy user.first_name NOT LIKE '%J'
Contains	Firts Name	%o%	Copy user.first_name LIKE '%o%'
Not contains	Firts Name	!%o%	Copy user.first_name NOT LIKE '%o%'

Numbers and date fields

Type	QBE Param	QBE Value	SQL clause
Greater than	Birth Date	>21-05-2019	Copy user.birth_date > MDY(5, 21, 2019)
Greater or equal then	Birth Date	>=21-05-2019	Copy user.birth_date >= MDY(5, 21, 2019)
Lower than	Birth Date	<21-05-2019	Copy user.birth_date < MDY(5, 21, 2019)
Lower or equal than	Birth Date	<=21-05-2019	Copy user.birth_date <= MDY(5, 21, 2019)
Between	Birth Date	01-01-2019:31-12-2019	Copy user.birth_date BETWEEN MDY(1, 1, 2019) AND MDY(12, 31, 2019)
Not between	Birth Date	!01-01-2019:31-12-2019	Copy user.birth_date NOT BETWEEN MDY(1, 1, 2019) AND MDY(12, 31, 2019)

In case of specifying more than one QBE param they are applied to narrow the filter, so they are joined by the AND operator. For example, applying the QBE params:

• Firt Name: John
• Last Name: Smith

The resulting SQL clause is:

user.first_name = 'John' AND user.last_name = 'Smith'

Notice that dates are introduced in the user format and time zone, and they are translated into the database format and time zone when applied.

By default, the SQL clause generated by the QBE is automatically applied to the main SQL statement of the object instance. For example, in case of having the following statement:

<select>
    <columns>*</columns>
    <from table='customers'/>
</select>

And receiving a QBE clause where the query field customers.cust_id is equal to 2 , then the executing statement will be:

SELECT * 
  FROM customers
 WHERE customers.cust_id = 2;

It works fine with single SQL fragments, which are the most common, but in cases of having more complex statements, with multiple fragments or script execution, it could be necessary to specify where to put the QBE clause. For example, when having the following statement:

<select intotemp='@tmp_customer'>
    <columns>*</columns>
    <from table='customers'/>
</select>
<select>
    <columns>*</columns>
    <from table='@tmp_customer'/>
</select>

And receiving a QBE clause where the query field customers.cust_id is equal to 2 , then the executing statement will be:

So in that case when can specify where to put the QBE clause with the expression $[grpname] , where group name is the code defined. By default, all Query fields have the same group name, with code 0 .

<select intotemp='@tmp_customer'>
    <columns>*</columns>
    <from table='customers'/>
    <where>
        $0
    </where>
</select>
<select>
    <columns>*</columns>
    <from table='@tmp_customer'/>
</select>

SELECT * 
  FROM customers
 WHERE customers.cust_id = 2
 INTO TEMP tmp_customer_001;
SELECT * 
  FROM tmp_customer_001;

This functionality allows having specific attributes on an QBE field and keep SQL statement simple.

The attributes determine how columns behave in a form or report, with a variety of options determining display, input, etc. For further information, see Attributes in Data Modeling section.

To use all the columns of a table as input fields, it will only be necessary to enter the name of the table and an asterisk * in the Column field.

As a result, the report displays the query screen, which contains all columns of the stipulated table.

The variables are another mechanism for data filtering. They should be created when the inputs fields cannot be used due to the query complexity.

The variables allow defining input fields to be used in expressions that form the SQL sentence of an object. Each variable can define their own type and its way of being incorporated to the SQL sentence during the construction phase.

The variable input form has the following options:

• Order: order in which the system presents the input variables to the user. This command is subject to the input fields that the object has defined. The variables are placed behind the input fields.
• Table: Table name, if you want the label defined for any column in a table to appear as a description of the request of the variable, having to match the name of the column of this table with one of the variables. In the case that there are a description and a table, if it is found, the table is the one that prevails.
• Variable: code that is assigned to the variable. It will be the one used when including it in the SQL statement of the object, preceded by the $ character, regardless of the class and type it is.
  If a variable has been defined without having integrated it in the SQL statement of the object, the system will ignore it.

  Example

  Suppose that we define a variable to request an exercise. If we define the variable with the code EXERCISE, to integrate it into the SQL statement it would indicate $EXERCISE.
• Description: name or description of the variable that the system will present on the query screen.
• Default value: if you want the variable to have a default value at the time of the execution of the object, it will be reported here. The user can modify this value previously to the execution. By default, the system also supports SQL expressions and functions of the type: TODAY.

  xsql-text

  The tag <xsql-text> whose content is an xsql, will be transformed into the database agent on runtime.
  Example:
  <eval-date d='-1'>$FECINI</eval-date>
  will be transformed to:
  IDS: $FECINI - 1
  DB2: $FECINI -1 DAYS
  ORACLE: $FECINI - 1
  

• Letter case: allows passing the value of the field to Uppercase or Lowercase.
• Format function: name of the javascript function to format the field.

  They are javascript functions that are located in a module, which serve to format the field. This field corresponds to the name of the function.

  Functions must follow some specifications, and can be added to the module so that they can be used as a format for table columns. The repository of these functions can be found:

  Menu path:

  Dictionary / Physical / Attributes / Formatting functions

  See the section Data Modeling/Data decoration/Attributes/Input options/Format function.

• Type: select one among the existing options of varible types. These are Char, Date, DateTime, Integer, Decimal, Expression. For further information see section Variable type.
• Construct: through this indicator, the system is informed if the variable is going to have, in the construction of the SQL statement, a behavior equivalent to a construct field or input field.
• Lookup list: it generates a lookup field referencing a table.column object.
• Include Type: the include type will define how the user can select the values provided by the include that the variable has assigned. These are: Select, Multiple or none.
• Include: include code to be assigned to the field. This is recommended when the possible values of a variable correspond to fixed values or to records in a table.
• Query: only for construct type. It defines a different field to the column field so that it takes a logical dictionary with an alias, but when applying it to the SQL cond it makes a specific query.

  For instance, if we define a variable with the code EXERCISE, to integrate it into the SQL statement it would be indicated: $EXERCISE .

Two main causes that force you to create input variables:

• Selection criteria.

  As we mentioned when explaining the registration of input fields, there are some occasions when, in order to make selections by certain fields, it is not possible through that registration.

  The reason is that the name of the table in an input field is implicit in the field in the SQL syntax that the system constructs when querying the database. As the SQL statement of the object consists of several FROM clauses, for some it will be fine and for others, it will lead to errors because the table does not belong to the list of tables of that clause.

  In this situation, the most viable and advisable is, for these conflicting fields, to define query variables, since this way we avoid the mentioned errors and the same query can be made as through input fields.

• Processes. When the SQL statement of an object consists solely of activating a process to which certain parameters reported by the user are passed, the only way to request said parameters from the user is through input or query variables.

When the possible values of a variable correspond to fixed values or records in a table, it will have to be assigned an include.

This include will be the one that returns the possible values from its definition; hence it must be defined in the wic_jdic_colincl dictionary of includes.

There would be no point in assigning in a construct class variable a list of possible values, since a normal variable would be enough. In any case, the system would still work if the integration of the variable in the SQL statement is done taking into account that it is of this class.

The include type will define how the user can select the values provided by the include that the variable has assigned.

The type of variable is very important, since it must be in accordance with the type of values that the variable can accept. Taking this into account, the type of variable affects in case of assigning an include to the variable, the possible values that that include can provide.

Besides, the type of values that the variable supports must also be consistent with the type of field to which it will refer in the SQL statement of the object.

The types of variables that the system supports are the following:

• Char (character): this will be the type of variable to assign when the values to be entered in the variable are alphanumeric. When the system builds the query's SQL statement, the values of the variable will be enclosed in quotes: '' . An example of such a variable could be the code of an accounting account, a supplier, a customer, a warehouse, etc.
• Date: this will be the type of variable to assign when the values to be entered in the variable are dates. When the system constructs the SQL statement of the query, the values of the variable will be transferred in the form: MM-dd-yyyy (month, day, year).

  An example of such a variable could be any date to request.

• DateTime: this will be the type of variable to assign when the values to be entered in the variable are date and time, increasing the accuracy. When the system constructs the SQL statement of the query, the values of the variable will be transferred in the form: MM-dd-yyyy HH:mm:ss (month, day, year, hour, minutes, seconds)
• Integer: this will be the type of variable to assign when the values to be entered in the variable are numeric without decimals. When the system builds the SQL statement in the query, the values of the variable will be passed as they are. An example of such a variable could be an exercise, a period, etc.
• Decimal: this will be the type of variable to assign when the values to be entered in the variable are numeric with decimals. When the system builds the SQL statement in the query, the values of the variable will be passed as they are.
  An example of such a variable could be any number that must include decimals: amounts, quantities, weights, measures, etc.
• Expression: this will be the type of variable to assign when the values to be introduced to the variable consist of expressions based on SQL language that will be transferred to the SQL statement of the object as they are expressed. These types of variables are not usually reported by the user, but belong to objects that are run from some "wic_jrep_collnk" hyperlink. In that case, these types of variables are already reported with the corresponding expression.

Through this indicator, the system is informed if the variable is going to have, in the construction of the SQL statement, a behavior equivalent to a construct field or input field.

Whether or not this indicator is activated will influence the integration of the variable into the syntax of the object's SQL statement.

When a variable is defined as class construct, that is, this indicator is activated, it will always be included in the syntax of the object's SQL statement as follows: AND table.field $VARIABLE , regardless of whether the variable is assigned an include, as mentioned in the include type field.

When the system constructs the SQL statement of the query for a variable of this class, depending on the information supplied by the variable, the system will intelligently use the necessary logical operators based on it.

The most usual examples are the following:

• = . When the variable supplies a single value, for example an fiscal year, the system will create the statement of the form: table.field = 2000 .
• IN () . If instead of supplying a single fiscal year, you get two values separated by a | , then the sentences would be: table.field IN (1999,2000) .
• MATCHES . If the value supplied by the variable is linked with a * , in this case, the statement would be: table.field MATCHES '* value *' (depending on whether the * has been reported to the left, right of the entered value, or both sides.)
• BETWEEN . If the values supplied by the variable arrive separated by : , then the statement would be: table.field BETWEEN value1 AND value2 .
• etc.

1. For a user executing an object to distinguish a construct variable from a normal one, the system presents them in different colors, so that the class construct is will show purple and normal green.
2. The content of this type of variables, in the context of an xsql-script program, must be defined as the unquoted attribute according to the following example: <p_empcode mode='unquoted' />

In many cases, the value to be reported to a variable consists of the code of some concept existing in a table in the database.

To facilitate the introduction of the values for the user, it could be possible to assign an include to the variable. This would produce the list of existing records in that table.

This option may be inconvenient for the user if the table, from which the values are obtained, contains a significant number of records. Besides, it could be unfeasible if the number of records is very high.

For these cases, the system is provided with an option to enable help to the user at the time of the object's execution. This option is independent of the number of records and does not overload the system.

It consists of informing in the Lookup field, the table.column where the necessary data to inform the variable is found. The name of the table represents the name of the object that displays the records of that table.

However, the table name would not necessarily have to match the name of an object in a master table, but could be any object defined by the user. For this to be the case, the object must contain, as a table and an output field, the name of the table and the field indicated here. Otherwise, the system would not know how to identify which of the output fields of the user object would have to get to report in the variable input.

In the latter case, it should be taken into account that the object should be a simple object, in the sense that it does not contain breaks, totalizers, etc. Nor does it make sense for the field to be obtained for the aid, to appear repeatedly in the records of that object, since then it would lose its usefulness.

Through this option, the system shows the user the records of that table. As the user selects records, the system will transfer the existing values to the variable field, a field that corresponds to the column linked to the table reported here.

The user can also use this option as a query, so that they do not necessarily have to select records, but simply query the data they wanted to know, and they can close the query without having selected anything. Subsequently, the user will enter the desired value in the variable.

The possible values of the include type and its functionality would be the following:

• Select one. When the include is of this type, the user can only select one and only one of the possible values that the variable shows. In this case, it is normal that the variable was not of class construct.

  Assuming this is so, the variable should be considered in the WHERE clause of the object's SQL statement, as follows:

  AND table.field=$VARIABLE,

  being table one of the tables belonging to the list of tables indicated in the FROM clause of the SQL statement, being field one of the columns of the table in question and VARIABLE the code of the corresponding variable.

  When the user chooses one of the possible values of the variable, the system will construct the SQL statement assigning to the variable the chosen value. If the variable were defined as class construct, then it should be considered in the WHERE clause of the object's SQL statement, as follows:

  AND table.field $VARIABLE.

  In this case, the system already takes care of, in addition to substituting the chosen value, interposing the = operator in the construction of the SQL statement of the query.

• Select multiple. When the include is of this type, the user will be able to select more than one value (multiple selections) of the possible values that the variable shows.

  In this case, as in the previous case, it is normal for the variable not to be of class construct. Assuming this is so, the variable should be considered in the WHERE clause of the object's SQL statement, as follows:

  AND table.field IN ($VARIABLE)

  If the variable were of type construct, the syntax of the SQL statement would be the same as in the previous case, but in this case, the system will build the statement by adding the IN() automatically.

  
• None. This value will be the one assigned when the variable does not have an include assigned.

When the possible values of a variable correspond to fixed values or records in a table, it will have to be assigned an include. This include will be the one that returns the possible values from its definition; hence it must be defined in the system includes dictionary.

There would be no point in assigning in a construct class variable a list of possible values, since a simple variable would be enough. In any case, the system would still work if the integration of the variable in the SQL statement is done taking into account that it is of this class.

For further information on includes, see the section Selection controls (Includes).

When the system constructs the SQL statement of the query for a normal variable, the system will integrate the variable value literally, with not possible logical operators.

When the system constructs the SQL statement of the query for a construct variable, the system will intelligently use the necessary logical operators based on it.

When the system constructs the SQL statement of the query for a construct variable, the system will intelligently use the necessary logical operators based on it. If, in addition, the variable has a column.field defined in the variable query field, the system will automatically integrate these into the construction.

For further information of variable Query name, see previous section Query Input Variables: Query.

The attributes determine how columns behave in a form or report, with a variety of options determining display, input, etc. For further information, see Attributes in Data Modeling section.

The SQL conditions or Filter consist of establishing selection criteria with fixed conditions associated with an object, in such a way that, when executing that object, the system will enable the meta queries of the object in question. This way the user, in addition to the indicated dynamic selection criteria, can (optionally) select one of the meta queries to set conditions for selecting it.

They are also known as meta queries.

The SQL conditions are defined in the Metaquery tab of the object, and are all accessible through the menu:

• Order: order in which the system presents the SQL conditions to the user.
• Code: a unique identifier, preferably use capital letters.
• Title label: the title field corresponds to the label code that the application will show the user on the QBE screen to select the SQL option. This way it must be possible for the meta query to have language descriptions.
• SQL condition:

  The condition indicated here will be the one that the system will add and concatenate to the original condition of the object to which the meta-query is assigned, at the time it is executed.

  There are several considerations to keep in mind:

  • When the system adds the SQL condition established here to the object, it does it in the following way: AND SQL condition meta query, so that the operator AND is automatically preceded by the system itself, hence its inclusion in this condition is not necessary.
  • If the object to which the meta query belongs has query variables, these are also susceptible to use and include in the SQL statement of the meta query.
  • The system includes by default a series of standard variables that can be very helpful and can also be used in the SQL condition. These are:
    • $USER. The content of this variable refers to the code of this user.
    • $DBMS. The content of this variable refers to the code of this database.
    • $LANG. The content of this variable refers to the language code of this user.
  • The system supports the inclusion of some XML tags for the correct transformation of some SQL functions that depend on the database agent where it runs. For example, the function NVL is valid in Informix and Oracle, but in DB2 it is called COALESCE and in MySQL IFNULL, and using the XML tag <nvl> it is transformed to the corresponding one. To concentrate all the possibilities, you can write these supported functions in XML, including the entire condition between the tags <xsql-text> and </xsql-text>, to indicate that it must be transformed previously.

    Example

    Copy

    EXISTS(
      SELECT gcomalbl.cabid
        FROM gcomalbl, gcommovl_datc
       WHERE gcomalbl.linid = gcommovl_datc.linid
         AND gcomalbl.cabid = gcomalbh.cabid
         AND LENGTH(NVL(gcommovl_datc.codpre, gcomalbh.codpre)) > 0
    )

    It would be written:

    Copy

    <xsql-text>
    EXISTS(
      SELECT gcomalbl.cabid
        FROM gcomalbl, gcommovl_datc
       WHERE gcomalbl.linid = gcommovl_datc.linid
         AND gcomalbl.cabid = gcomalbh.cabid
         AND <length><nvl>gcommovl_datc.codpre, gcomalbh.codpre</nvl></length> > 0
    )
    </xsql-text>

Through this option we access to the definition of the object output fields. If the user has the required authorizations, it is possible to create, modify and delete such definitions.

The Output fields are defined in the Output tab of the object, and are all accessible through the menu:

• Order: order of presentation (from left to right) of the columns in the object.
• Table and column:

  name of the table to which the column to be registered as the output field belongs. When the column has an alias, this has to be reported in this column field.

  The table reported here should be defined in the wic_jdic_tabdata table dictionary, and in combination with the column to register, in the wic_jdic_coldata column dictionary. The fact that they are registered in this last dictionary is important because it will depend on the system showing the descriptions abbreviated from the dictionary, such as column titles.

  ATTENTION

  Keep in mind that some character have special treatment: ¡!""#$%&'`´()*+,-.¨·/:;<=>¿?^@|\\[{}; the system will replace them with _ (underlined); these characters are not allowed for the name of a table.

• Real column: the real column corresponds to the real name of a column when it uses an alias in the output column field. For example, when the select obtains columns from several tables, there is a possibility that some of the columns share the same name. Because they are primary keys, in these cases it is mandatory to define an alias for them, which is the one that we will insert in the output column field. Then the real name of the column must be put in the Real column field.
• Group:

  TO DO

  This section is incomplete and will be concluded as soon as possible.
• Header:
• Aggregate:
• Hidden:
• Input: input type. There are three input modalities.
  • Auto: the system determines automatically whether the field is entry or no entry.
  • Entry: forces a field, which is not physically editable, to be logically editable (in the form)
  • No entry: forces an entry field, to be no entry.
• Decimals:

  By means of this parameter, we indicate to the system the number of decimal places of precision that we want to show us in a numerical field.

  When you want the system to display the same number of decimals as that of the field's own physical definition within the table to which it belongs, then we will indicate the value -1 here. This value is the one presented by the default system. In fact, for those fields that are alphanumeric it will be the value used, regardless of the one that has been reported.

  If the physical definition of the field does not support decimals, the system will not display decimals even if it is prompted to do so. To do so, it would be necessary to vary the physical definition of the field itself.

• Formula: formula to be applied to determine the value of the column. The value is calculated for each record with the values of the columns involved in the formula.
• Events: