The following document tries to introduce the reader to the Object instance. After reading this article, the reader will know what is an Object instance, how to create and configure it, and which functionalities it implements.

1 Introduction

Every view on WebApp application (Reports, Transactional forms, Rest APIs, etc.) is an instance of this Object entity. This implementation gives a centralized configuration for views, such us the tree menu configuration and views functional grouping.

Furthermore, when defining references to an Object through the application, such as links, automated executions, etc. those reference point to a unique entity, the Object Instance, whatever the type of Object it is.

Finally, most of the Objects require a process of query in order to narrow the data to be displayed on the view. This is what we call QBE (Query By Example); which consists on a set of parameters that provide the user a user friendly form with a set of input fields for specifying what data wants to manage. So, the Object instance provides the entities: Query fields, Query variables and SQL Conditions to implement the mentioned QBE.

To sum up, the Object instance is intended for providing:

  • Simplified application menu configuration.
  • Simplified Object references within application.
  • Centralized description and localization.
  • Centralized query.

2 Definition

Review pending

To define an object instance, it is necessary to access the definition form wic_obj_base in the application dictionary.

Menu path:
Objects / Definition / Objects (New)

The definition form is divided in parts, all common to all object types except for the Report tab, which is unique for Report instances.

  1. Report tab: only for report instances
  2. Identification:
    • Object code*: It must be the unique identifier. Use conventional syntax, with lowercase letters and underscore between separate words. Preferably, 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 and serves two major functions. On the one hand, to assign role permissions through the wic_conf. On the other, to control some aspects related to the appearance and color of the object.
    • Type*: select between Report (0), Transactional (1) of REST Application (2). Report (0) set by default.
    • Locked: if the locked box is disabled, then the object can be selected and executed. Enable it if the object is being design or under revision.
  4. Input tabs:
    • Input query: defines the fields on the query form.
    • Input variables: defines complex query fields.
    • Input meta query: defines quick access query fields.
  5. Help tabs:
    • Object info: help text description to be reported when user clicks on object instance help icon. Use PARSEXML format.
    • Snapshot: picture of an object instance example.
    • Language: allows name and title of the object to be translated into other languages.
  6. Control data: standard information about object instance.
    • ID: instance identification number.
    • Created by: user who created it.
    • Date created: date of registering.
    • Modified by: user who modified it.
    • Date updated: date of last update.

3 Input query fields

Review pending

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:

Query fields are only applicable to the following object types:

  • Reports
  • Transactional

The components that define a query field are:

  • Order: the order in which the input fields will appear.
  • Group: allows grouping query fields to be used separately in statement. The default value 0 is equivalent to $set. Review pending Use $QRY1, $QRY2, ..., instead of the unique $0. Different groups of input fields can be implemented, for example, so that some selects only affect a subset of fields.
  • Table: 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.
  • Query: 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.
  • Required: determines whether a query field is required and if it will be display in the main query screen or the secondary one. All required fields will display an *asterisk to let the user know that it is a mandatory field.
  • Default: allows assigning default values to a query field.

SOFT REFERENCES

The input field inherits the soft reference from table and column definition. Soft Reference implementation is detailed in chapter Advanced features, section Soft References.

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.

Attention

When the SQL statement of an object consists of two SELECT clauses joined by a UNION or UNION ALL clause, it could happen that the tables registered in the input fields of the object were valid for one of them and not for the other, which would lead to the error that the table does not belong to the list of tables indicated in the clause.

This could happen because as the input fields have the name of the table implicit, if any of the tables in those fields were not included in the FROM clause of any of the instructions, this would lead to an SQL error.

When such a case occurs, it is recommended to use and define query variables for those input fields that are not common and valid for this type of SQL constructs. Query variables do not imply the name of any table; which would allow skipping the error that occurred previously.

3.1 Order

The input order will be the one corresponding to the order in which the system will present the input fields to the user, when entering the selection criterion.

If the object had query variables associated, the input fields are displayed first, and afterwards the variables are displayed.

3.2 Group

The Group defines to which functional group it belongs. Functional groups in combination with functional roles will allow the application to dynamically adapt user menus.

Functional groups are pre-defined in the wic_jrep_roles object.

Menu path:
Objects / Auxiliaries / Functional groups

3.3 Table and Column

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.

IMPORTANT

As a column name, the character * would be accepted.
This option avoids having to register all the columns of the mentioned table. This would be equivalent to registering as input fields, of all the columns belonging to the indicated table.

3.4 Query

By default, fields tabname and colname act as a driver to retrieve logical data like labels, attributes, soft-references or the possible list of input values. All them relay upon the logical dictionary definitions.

Besides, the query field allows to apply another condition in the execution of the SQL statement.

The text, code, column or table.column filled here do overtake the default values stored as tabname and colname. Moreover, the content applies without any kind of transformation as a "left-side" of the row condition.

In this case, the virtualstudio table has no physical schema. The input query shows the virtualstudio.state label, but the report will show the results of employees in an "A"ctive state of the studio_employees.state field.

Examples of allowed data:

Tabname Colname Query field Statement results
cproyect codigo WHERE cproyect.codigo = ?
cproyect codigo proyec WHERE proyec = ?
cproyect codigo UPPER(proyec) WHERE UPPER(proyec) = ?
cproyect codigo capuntes.proyec WHERE capuntes.proyec = ?

3.5 Default

Query fields allow specifying a default value on by specifying one value on the Default 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.

3.6 Required value

Query fields can be marked as required via the Required attribute at Query Fields entity (wic_obj_inputqry.qry_isrequired ).

This field can take three possible values:

  • Important: the field will appear on the main query screen (in contrast with unusual). If present, click on the See more field in order to see secondary screen.
  • Unusual: the field only appears if user displays the secondary screen of the query.

  • Required: the query is not executed until this field is filled. Note that required fields will be marked with an asterisk* in the query screen.

    Setting a query field as required has two affectations in Axional Studio application:

    • Invalidating the form at QBE page until all required query fields are filled. So, the query cannot be executed from QBE page if there are missing values on required query fields.
    • All URLs executing an object with missing required query fields will be redirected to the QBE Page. That is, by no means an object will be executed without specifying a value for a required query field.

3.7 Syntax

TO DO

This section is incomplete and will be concluded as soon as possible.

3.8 Use in statement

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.

3.8.1 QBE to SQL conversion

The tables below contains 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)

Multiple fields

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:

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

Dates handling

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.

Basic Text Search (BTS)

TO DO

This section is incomplete and will be concluded as soon as possible.

3.8.2 QBE statement application in SQL

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:

Copy
<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:

Copy
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:

Copy
<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:

TO DO

Explain what happen with the where clause when exists more than one fragment and it is not specify where to put the where clause.

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 has the same group name, with the code 0 .

Copy
<select intotemp='@tmp_customer'>
    <columns>*</columns>
    <from table='customers'/>
    <where>
        $0
    </where>
</select>
<select>
    <columns>*</columns>
    <from table='@tmp_customer'/>
</select>
Copy
SELECT * 
  FROM customers
 WHERE customers.cust_id = 2
 INTO TEMP tmp_customer_001;
SELECT * 
  FROM tmp_customer_001;

TO DO

This section is incomplete and will be concluded as soon as possible.

Use of variables

TO DO

This section is incomplete and will be concluded as soon as possible.

3.8.3 Specific SQL clause

TO DO

This section is incomplete and will be concluded as soon as possible.

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

3.9 Dictionary attributes

TO DO

This section is incomplete and will be concluded as soon as possible.

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.

3.10 Select all columns

Review pending

To select all the columns of the table without having to specify one by one, it is only necessary to create an input with the table name and an asterisk * in the column. This will include in the query input all the columns defined in the table.

4 Query input variables

Review pending

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

Query variables are only applicable to the following object types:

  • Reports

The variable input form has the following options:

  • Order: order in which the system presents the input variables to the user.
  • Group: the group name corresponds to the variable name, which will be use in the statement. Syntax: VARNAME (alphanumerical characters).
  • Table and column: table and column to take the logycal dictionary.
  • 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.
  • Type: select one among the existing options.

4.1 Criteria to create input variables

There are two main causes that force you to create input variables:

  • Selection criteria .

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

    The reason is because 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.

NEW FEATURES

NULL VALUES ALLOWED. Now a null value for a variable is allowed as long as the variable is not marked as required.
SOFT REFERENCES. The query input field inherits the soft reference from table and column definition.

When the possible values of a variable correspond to fixed values or to 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 possible values of the include type and its functionality would be the following:

  • Select. 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 fieldone 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.
  • Multiple. When the include is of this type, the user will be able to select more than one value (multiple selection) 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.

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

4.3 Group

Review pending

Name that is assigned to the variable, which 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, it will be equivalent to not having defined it; that is, the system will ignore it.

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.

4.4 Table and column

Review pending
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 the one of the variable. In the case that there is description and a table, if it is found, the table is the one that prevails.

 

4.5 Query

Review pending

The query column of the input fields of an object allows to take, from the logical dictionary, the attributes defined by tabname and colname but at the same time to apply another condition in the execution of the SQL statement.

Using this method you can avoid having to define the table and column before the variable in the STATEMENT of the object.

This option is only valid for construct type variables

You can inform this query field in several different ways:

  • column: if you only inform the name of a column, the select will take the table defined in the previous field Table. This is the case of the VAR_DATE_CONSTRUCT variable example, that will take the field_date column of the studio_field_types table.
  • table.column:the select will take the table and column here informed. This is the case of the VAR_INT_CONSTRUCT variable example, that will take take the studio_field_types.field_int table and column instead of the virtual studio table.

Note that you can write the query field in both upper or lowercase letters.

4.6 Type of variables

Review pending

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.

In addition, 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, secons)
  • 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.

4.7 Default value

When you want the variable to have a default value at the time of the execution of the object, it will be reported here. 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 to 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

4.8 Required value

Mark this field to make this value required on query screen.

4.9 Construct

Review pending

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.

Note that, if a Query field has been previosly defined with a table.field name , it is not necessary to integrate it in SQL Statement.

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. In order 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 the unquoted attribute according to the following example: <p_empcode mode='unquoted' />
 

4.10 Soft references

The query input field inherits the soft reference from table and column definition. It is possible to inform a different soft reference that will work only in the query screen. This can be useful to avoid dependencies soft reference of the table and column.

  • If no soft reference is informed here, the query input field inherits the soft reference from table and column definition.
  • If a new soft reference is informed here, the query input field will use this new one instead of the one related to the table.column.

Soft Reference implementation is detailed in chapter Advanced features, section Soft References.

4.11 Use in statement

TO DO

This section is incomplete and will be concluded as soon as possible.

4.11.1 Normal variables

Review pending

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.

Normal variable, select and query

SELECT*
FROM mytable WHERE colname=$MYVAR

  • $MYVAR = 'A'
    • ...WHERE colname = 'A'
  • $MYVAR = 'A*'
    • ...WHERE colname= 'A*'
  • $MYVAR = '!=A'
    • ...WHERE colname = '!=A'

IMPORTANT

The normal variables do not accept a variable query name.
 

4.11.2 Construct variables

Review pending

Construct variables without variable query name

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.

IMPORTANT

Construct variables do not need the = symbol in the SQL statement syntax, as they construct it automatically.
Construct variable with variable query name: select and query

SELECT*
FROM mytable
WHERE colname $MYVAR

  • $MYVAR = 'A'
    • ...WHERE colname = 'A'
  • $MYVAR = 'A*'
    • ...WHERE colname LIKE 'A%'
  • $MYVAR = '!=A'
    • ...WHERE colname !='A'

Construct variables with variable query name

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.

Construct variable without variable query name: select and query

SELECT*
FROM mytable
WHERE colname $MYVAR

  • $MYVAR = 'A'
    • ...WHERE mytable.colname = 'A'
  • $MYVAR = 'A*'
    • ...WHERE mytable.colname LIKE 'A%'
  • $MYVAR = '!=A'
    • ...WHERE mytable.colname !='A'

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

QBE to SQL conversion

TO DO

This section is incomplete and will be concluded as soon as possible.
QBE statement application in SQL

TO DO

This section is incomplete and will be concluded as soon as possible.
Specific SQL clause

TO DO

This section is incomplete and will be concluded as soon as possible.

4.12 Dictionary attributes

TO DO

This section is incomplete and will be concluded as soon as possible.

4.12.1 Alternative columns

TO DO

This section is incomplete and will be concluded as soon as possible.

5 SQL Conditions (Meta query)

Review pending

The SQL conditions 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 SQL conditions of the object in question. This way the user, in addition to the indicated dynamic selection criteria, can (optionally) select one of the SQL conditions to set conditions for selecting it.

Meta queries are only applicable to the following object types:

  • Reports
  • Transactional

5.1 Order

The input order will be the one corresponding to the order in which the system will present the SQL conditions drop list to the user, when displaying the SQL condition field in the QBE.

5.2 Code

This code must be a unique identifier, preferably using capital letters.

5.3 Title

The title field corresponds to the label code from the wic_jdic_lbldata that application will show the user in the QBE screen when selecting the SQL condition option. This way it must be possible the SQL condition to have language descriptions from that label defined in the wic_jdic_lbldata.

5.4 Condition

The SQL condition indicated here will be the one that the system will add and concatenate to the original condition of the object to which the SQL conditions 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 , 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 SQL conditions belongs has query variables these are also susceptible to use and include in the SQL statement of the SQL conditions.
  • 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.

5.4.1 SQL functions transformation

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

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 will be writen:

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