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.

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.

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.

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.

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

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.

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.

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:

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.

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.

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.
   • Action: upgrade.
     
     
     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.

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.

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.

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.

• 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.

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.

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.

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.

• 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.

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.

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.

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.

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.
• 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.

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

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.

// =========================================================================
//  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);
}

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.

// =========================================================================
//  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.

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 $

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*: 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: 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.

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

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

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).

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.

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.

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

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.

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)
   Menu path:

   Dictionary / Physical / Attributes / Soft references (definition)
2. Field helper relation (wic_jdic_softref_rel)
   Menu path:

   Dictionary / Physical / Attributes / Soft references (relationship)

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

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

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.
  

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

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

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

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.