Arithmetic Expressions

Arithmetic expressions use arithmetic operators to combine operands (typically value expressions). When evaluated, these arithmetic expression yield a numeric result, if possible.

Operator

Meaning

+

Positive sign (unary +); addition

Negative sign (unary -); subtraction

^

Exponentiation

*

Multiplication

/

Division

Note: If the ^ character is unavailable, you can substitute **.

The standard rules of precedence for arithmetic evaluation are used.

Examples of arithmetic expressions follow:

Salary * 1.1

Salary + (Salary*0.1)

(! + InterestRate)^Years

The data types (CHAR, NUMERIC, INT, and so on) of the operands used in an arithmetic expression can be mixed. Operands that are character strings are translated (if possible) into an equivalent number, as shown below:

‘/’ evaluates to 0

‘-2’ + 5 evaluates to 3

‘2’ * ‘-4’ evaluates to -8

If a character string cannot be translated into a number (e.g., abcd), then an error message is returned, or the operand is treated as if it were zero.

Multi-Language Support

Customizing applications for languages other than English

In Zim applications, some information that appears in the user interface, such as data masks, and error and processing messages, is language dependent. Zim provides tools to handle these dependencies and to make the application appear to the application user in languages other than English. A single application can be designed to handle several different languages simultaneously.

Language dependencies occur in four major areas of any application:

  1. Character handling
    • definition of non-English characters
    • uppercase/lowercase translation
    • collating sequence for sorting, indexing, and comparing
  1. Zim errors file
    • errors produced by Zim itself
  2. Internal messages and strings
    • errors and processing messages produced for the application’s forms
    • day and month names
  3. Data masking
    • numeric masks
    • alphanumeric masks
    • date masks

Tools used for adaptation

Zim provides three tools specifically geared to language adaptation:

  • the developer-defined collating table
  • the ability to translate error messages
  • the ZIMLANG utility to alter masks, day names, and so on

The collating table is stored in the database. The collating table defines, internally to the system, how characters are represented and how they are to be sorted.

You can provide your own collating tables. For applications in languages other than English, the collating table enables you to properly handle special characters, such as accented characters.

Messages, strings, and mask characters can be customized for the desired language by translating the error message file or calling up the ZIMLANG utility.

Restrictions

Although Zim’s language-independence features solve a number of language adaptation problems, keep in mind these restrictions:

  • Applications are developed in English
  • You must ensure that output from an application is properly translated into the required language(s)

Numeric input/output can be adapted to another language only if it is controlled by a mask or numeric form field. Numeric values input from documents, including the terminal, or output without masks, appear in the original English format.

Zim does not recognize multi-character currency symbols.

Character Handling

Some languages use more characters than the twenty-six found in the English alphabet. These extra characters must be defined to ZIM in the collating table.

Collating Information

Zim uses a collating sequence that the database initialization program ZIMINIT reads from a collating table stored in an operating system file. The name of the collating file is operating system dependent. If the collating table is not found, Zim uses the standard collating sequence for your operating system.

Applications that have a requirement to define a collating sequence other than the standard ASCII collating sequence (i.e. programs that use accented characters) should rename the appropriate collating file in the Zim software directory to ” COLLATE.ZIM”. Renaming the file ensures that it is read by the Database Initialization program. In Zim for Windows, ZCOLLATE.DOS defines a collating sequence for all the OEM-accented characters while ZCOLLATE.WIN provides a collating sequence for the ANSI-accented characters.

The collating file is a text file that can be modified with any text editor that can handle ASCII characters. The file contains one entry per line. Each entry consists of the following information:

  • character representation (the internal value that represents the character)
  • collating value (the sorting value assigned by to the character by the developer)
  • lowercase representation (the lower case equivalent of the character)
  • uppercase representation (the upper case equivalent of the character)

Each field in an entry is separated from the next by a space. The characters can be entered as single characters that exist in your hardware’s character set or as a hexadecimal value. Hex values are entered in the format

hh

where hh is a pair of valid hex characters (0 to 9, a to f, A to F).

Entries in the collating table are governed by the following rules:

  • A character is known as a letter if either its uppercase representation or lowercase representation differs from the value placed in the character representation field of the collating table.
  • A character is upper case if it is a letter and if the character’s uppercase representation (the entry in the “uppercase representation” field) is the same as the character representation.
  • Some characters, such as $, #, @ are the same regardless of case. Therefore the entry in either the “uppercase representation” field or the “lowercase representation” field is irrelevant.

Accented Characters

A developer can treat a series of similar characters in the same way. For example, the characters

  • á
  • â
  • Ã
  • a

can all be assigned the same collating value. For sorting purposes, à  and á would be treated the same way as a. This situation simplifies the data entry responsibilities of an application user. The user does not have to remember if a customer’s name, for example, contains an accent. On the other hand, record searches become more inefficient by having a wider scope (searches for records that contain a also return records that contain á and a).

The developer must decide if it is better for the application to differentiate between accented characters or to treat all similar characters in the same way. To differentiate accented characters, the developer can assign them collating values that correspond to user-defined locations in the normal collating sequence.

Zim error message translation

Error messages are produced from templates stored in the ZIM errors file. This file is described in Customizing Error Messages.

Error message prefixes ( eg *** Error***) and internally generated form messages can be modified using the ZIMLANG utility.

Using ZIMLANG

When customizing an application for a different language, internal strings (processing messages, day names, and so on) and mask characters must be taken into account. Strings and mask characters are customized through the ZIMLANG utility. For information on the use of the command, see ZIMLANG.

Internal strings

ZIMLANG can be used to modify the following types of strings:

  • error message prefixes ( eg *** Error***)
  • day and month names
  • form error messages
  • processing messages

When ZIMLANG is used to translate processing messages, formatting characters (such as / n, / r, / d) must not be changed, as they are the codes used to properly format the display of the messages.

Masks

Masks are used in reports and forms to precisely define how data is to be displayed. ZIMLANG can be used to replace the following mask characters with different characters:

  • Date
  • day (D)
  • month ( M)
  • year ( Y)
  • numeric
  • currency ($)
  • comma (,)
  • decimal point (.)
  • alphanumeric
  • various characters (?)

Several rules must be followed when translating mask characters with ZIMLANG:

  • The mask characters for day, month, and year must be unique (i.e. the mask for day c
    annot be the same as the mask for month).
  • The mask characters for the decimal point, the comma, and the currency symbol must be unique (i.e. the mask for the decimal point cannot be the same as the mask for the comma).
  • ZIM developers can specify masks in a report, in the $mask function, and for a form field. Masks are always specified in English (the default format). ZIMLANG affects only how application users see masks in form fields and how they see masked values in form fields, reports, and the $mask function.

In reports and in the $mask function,

  • only numeric masks are affected by ZIMLANG
  • when a numeric mask indicates the presence of a decimal point, comma, or currency symbol, the newly defined character is used.
  • application users never see the masks themselves, just the masked data.

In forms, all three classes of masks (date, numeric and alphanumeric) are altered by ZIMLANG, with the following results:

  • In date masks, the new characters for day, month, and year replace the English characters
  • In numeric masks, commas and decimal points in displayed values are replaced by the appropriate alternate language characters.
  • In alphanumeric masks, mask characters (such as ?) are replaced with an appropriately defined alternate language character.

See Also

$mask

How To Use Data Masks

Number Literals

A number literal is composed using the digits 0 to 9 and a decimal point (if desired). The number literal is automatically assigned the data type VASTINT, with a number of decimal places equal to the number of places shown in the expression.

The following numbers are examples of valid number literals:

5   234   0.5   468.55

The following groups of digits are not number literals

56,789   1 23

because the software does not enable commas or spaces to be used inside numbers.

Expressions and the $Null Property

An object that has not been assigned a value, or whose value is unknown, is considered to be $Null. For example, at the start of an application session, global variables do not have an assigned value, so each is considered $Null. If the name of an object with an unassigned or unknown value is used as an atomic expression, the expression is considered to be $Null.

The $Null property is special in two ways:

  1. Any arithmetic or functional expression that contains a $Null value expression evaluates to $Null.
  2. Any logic expression that contains a $Null value expression is considered logically false.

For example, if the variable Salary is $Null, then

Salary * 1.1 evaluates to $null, and Salary = 20000 is logically false.

However, you can successfully check if an expression is $Null. If Salary is $Null, then

Salary is $Null is logically true and Salary is not $Null is logically false.

Notice that conditional expressions involving the system variable $Null cannot use an = (equals) or <> (not equals) operator; instead, you must use the operator IS [NOT]. The use of IS and IS NOT emphasizes that $Null is a property and not a value.

Note: $Null can also be written Null.

Truth Tables

For Boolean Operators: AND, OR, XOR, NOT

For Conditional Operators: [NOT] BETWEEN, [NOT] IN, [NOT] LIKE, IS [NOT] $NULL

Truth Table for a Boolean AND Expression

expression1 AND expression2

If the conditional expressions linked by AND are

  • both TRUE, then the Boolean expression is TRUE.

  • both FALSE, then the Boolean expression is FALSE.

  • one TRUE and one FALSE, then the Boolean expression is FALSE.

Truth Table for a Boolean OR Expression

expression1 OR expression2

If the conditional expressions linked by OR are

  • both TRUE, then the Boolean expression is TRUE.

  • both FALSE, then the Boolean expression is FALSE.

  • one TRUE and one FALSE, then the Boolean expression is TRUE.

Truth Table for a Boolean X OR Expression

expression1 XOR expression2

If the conditional expressions linked by XOR are

  • both TRUE, then the Boolean expression is FALSE.

  • both FALSE, then the Boolean expression is FALSE.

  • one TRUE and one FALSE, then the Boolean expression is TRUE.

Truth Table for a Boolean NOT Expression

NOT expression1

If the conditional expression preceded by NOT is

  • TRUE, then the Boolean expression is FALSE.

  • FALSE, then the Boolean expression is TRUE.

Truth Table for a [NOT] BETWEEN Expression

expression1 [NOT] BETWEEN expression2 AND expression3

A BETWEEN comparison is TRUE when

  • expression1 is equal to or greater than expression2 and equal to or less than expression3

A NOT BETWEEN comparison is TRUE when

  • expression1 is less than expression2

  • expression1 is greater than expression3

The [NOT] BETWEEN comparison is FALSE in all other circumstances.

Truth Table for a [NOT] IN Expression

expression1 [NOT] IN (expression2 [«,expression3 »])

An IN comparison is TRUE when

  • expression1 is equal to one or more of the expressions listed in parentheses

A NOT IN comparison is TRUE when

  • expression1 is not equal to any of the expressions listed in parentheses

The [NOT] IN expression is FALSE in all other circumstances.

Note: Comparison ends as soon as a TRUE instance is found.

Truth Table for a [NOT] LIKE Expression

expression [NOT] LIKE pattern

A LIKE comparison is TRUE when

  • expression matches pattern.

A NOT LIKE comparison is TRUE when

  • expression does not match pattern

The [NOT] LIKE expression is FALSE in all other circumstances.

Truth Table for an IS [NOT] $NULL Expression

expression IS [NOT] [$]NULL

An IS $NULL comparison is TRUE when

  • expression evaluates to $Null

An IS NOT $NULL comparison is TRUE when

  • expression does not evaluate to $Null

The IS [NOT] $NULL expression is FALSE in all other circumstances.

Special Expression Formats

Expressions can be combined in special ways to produce concise program statements that nevertheless have tremendous power and flexibility. The special expression formats are

  • WHERE expression format

  • assignment expression format

  • grouped expression format

  • case expression format

How To Use the WHERE Expression Format

A WHERE subcommand can be appended to a value expression to control the evaluation of that value expression. The syntax is

valexpression WHERE logic_expression

where valexpression is any value expression.

logic_expression is any logic expression.

If the expression is complex, it must be enclosed in parentheses.

If the WHERE condition evaluates to $True, the value expression is evaluated. If the WHERE condition evaluates to $False, the value expression is not evaluated, and the entire expression is considered to be $Null.

The WHERE expression format is frequently used with the case expression format, the assignment expression format, or with aggregate functions.

Examples of the WHERE Expression Format

(Salary – 20000) where Salary > 20000

(Salary – 20000) is evaluated only if the condition is met. The entire expression format takes on the value of the arithmetic expression if the condition is met; otherwise, it is considered to be $Null (valueless). The following example

let i = {  1 where Age < 10,      
    2 where Age between 10 and 30,  
    4 where Age > 50, 3}

assigns a value to a variable based on Age. The following example

compute Employees evaluate (let TotSal =     
  $total(Salary where LastName = “Smith”))

totals the salaries of all employees named Smith.

How To Use the Assignment Expression Format

A LET command can be used within an expression to assign a value to a target as the target is being used in a value or logic expression. The syntax is

(LET target=expression)

Where target is a global or local variable, a parameter, a field or a form field

where expression is any value expression.

Assignment expressions enable you to use fewer commands to achieve a particular result or to perform calculations within set-processing commands.

 

Examples of the Assignment Expression Format

while (let vCount=vCount-1)>0

Tests that vCount (which is first set to vCount – 1) is greater than 0.

let vTriple=(let vSingle=5)*3

Sets vSingle to 5 and vTriple to vSingle * 3.

(let vCount=vCount+1) where Processed=”yes”

Increments VCount if Processed is “yes”.

report footing (let TotalSal=$total(Salary)*1000)

Sets the variable TotalSal to 1000 times the running total of Salary, displaying TotalSal in the report footing. After the latter command has been executed (i.e., when the report is finished), the application retains access to the contents of TotalSal.

How To Use the Grouped Expression Format

Individual value expressions may be placed in parenthesis and separated from one another by commas to produce “grouped expressions”. The syntax is

(expression «,expr»)

where expression is any value expression. If the expression is complex, it must be enclosed in parentheses.

All the expressions are evaluated. The entire expression takes on the value of the last expression in the group.

Grouped expressions are useful for performing multiple assignments within one logic expression.

 

Example of the Grouped Expression Format

while ((let vTotal=0), (let vAverage=0), (let vCount=vCount-1)) > 0

let var1=((let var2=2), (let var3=3), 5-4)

How To Use the Case Expression Format

Case expressions provide a powerful method of dealing with evaluations that are conditional on the results obtained. The syntax is

{expression«, expr»}

where expression is any value expression, including another case expression.

The expressions within the braces are evaluated from left to right. The entire expression takes on the value of the first expression that is not $Null (valueless).

Each case within the braces is evaluated from left to right until one case yields a value that is not $Null. The case expression returns this value.

Case expressions can minimize the code that is required to produce certain conditional results as shown in the following example:

let Status = {“tall” where Height > 6, “short”}
replaces
if Height > 6
  let Status = “tall”
else
  let Status = “short”
endif

Case expressions can ensure that a value is provided in situations where a field or form field alone may sometimes be $Null, as shown in the following example:

let Salary = {fAddEmps.Salary, 0}

Case expressions can also be used to determine the action to be taken by certain commands, as shown in the following example:

break 1
  {$year(InvDate) + 1 where $month(InvDate) >= 5,
  $year(InvDate)}
  heading …

 

Examples of the Case Expression Format

let Status={“tall” where Height>6, “short”}

let ESalary={fAddEmps.Salary, 0}

detail line “Employee Number: ” {EmpNum, “N/A”}

 

See Also

$value

CASE

System Variables

The software maintains a series of system variables that represent either fixed values ($ZimOS) or values that fluctuate dynamically with the current status of the software ($InTransaction) or of application objects (ThisWindow.WindowTag).

System variables resemble global variables in nature. The software automatically sets or resets the values of system variables to reflect the status of the software and the current application. In some cases, an application program can also reset them.

A system variable name can be used as an atomic expression denoting the value currently held in the memory location associated with the variable. A system variable name can be used almost anywhere that a literal can be used.

Available System Variables

System variables are categorized into those that supply information about windows, those that supply information about menus, those that supply information about forms, and those that supply general information. Some system variables are “binary” in nature in that they evaluate only to ‘1’ ($True) or ‘0’ ($False), while others may be set to a variety of values.

General-use System Variables with “Permanent” Values

Given a particular version of the software, the following system variables have the same value at all times during an application session:

$ClipPath

Path to the disk directory to be used for Cut, Copy, and Paste operations that involve user interface objects in the Screen Painter.

$DBCharSet

Indicates the character set used by the application database.

$DBPath

Path to the disk directory in which the application database is stored.

$False

A “binary” false value for comparison.

$ImagePath

Path to the disk directory containing image files for use in forms.

$Null

A “null” value for comparison.

$TimeSecs

The elapsed number of seconds since 12:00am, 1 January 1970.

$True

A “binary” true value for comparison.

$WorkPath

Path to the disk directory where the application users’ work fields can be found (specified in a Zim configuration file).

$ZimOS

Identifies the operating system in use.

$ZimPath

Path to the disk directory in which the Zim software is installed.

$ZimProduct

Identifies the Zim product currently being used.

$ZimVersion

Identifies the Zim version currently being used.

General-use System Variables with Values Derived from the Operating System

The software sets the values of the following system variables based on current values obtained from the operating system:

$Date

The current date.

$GroupID

The current user’s operating system group identifier.

$ScreenHeight, $ScreenWidth

The size of the terminal screen in character rows/columns.

$Time

The current time.

$UserID

The current user’s operating system user identifier.

System Variables Periodically Set/Reset by the Software or the Application System

The values of these variables are set and reset depending on conditions encountered during execution of the application. An application program can assign a value to any of these variables at any time; however, the assigned value can be overwritten as conditions subsequently change during the application session.

Last Callback Event

Event is a data structure that provides information about the application environment the time of the most recent callback even. Each variable in the structure provides one item of information. The values of these variables are reset each time a callback event returns control to the application program. An application program can assign a value to any of these variables at any time; however, the assigned value is overwritten the next time that a callback event occurs.

Event.AltKey,
Event.CtrlKey,
Event.ShiftKey

The state of the Alt, Ctrl, and Shift keys during the last event.

Event.EventName

The last event to occur.

Event.EventTag

The object in which the last event occurred.

Event.EventType

The type of event that last occurred.

Event.FieldTag

The current field at the time of the last event.

Event.FormTag

The current form at the time of the last event.

Event.KeyPressed

The key that, when pressed, caused the last event to occur.

Event.MenuItemTag

The selected item on the menu in the current window at the time of the last event.

Event.MenuTag

The current menu at the time of the last event.

Event.MouseClick

If a mouse button accelerator caused an event to occur.

Event.ScrollingKey

If an event corresponds to a defined SCROLL key.

Event.WindowTag

The current window at the time of the last event.

Text Cursor Positioning

$CursorCol, $CursorRow

The location of focus in a window when an event occurs.

$CursorScreenCol, $CursorScreenRow

The location of focus on the screen when an event occurs.

$Direction

The direction in which focus was moving when an event occurs.

Error Status

$ErrCode

The error code generated by the last command executed.

$ErrLevel

The error severity level generated by the last command executed.

$LastErrCode

The error code generated by the last command that returned an error code.

$LastErrLevel

The error severity level generated by the last command that returned an error severity level.

$LastErrMessage

The error message generated by the last command that returned an error code.

$MaxErrLevel

The highest error severity level generated during the application session.

$SQLErrCode

The error code returned from the SQL database.

$SQLErrMsg

The error message returned from the SQL database.

Other Status Conditions

$BreakFlag

If the application user has pressed the “break” key.

$DeadlockReason

The reason that a deadlock condition occurred.

$InTransaction

If an explicit transaction is in progress.

$Located

The number of records located by a LOCATE command.

$MemberCount

The number of records processed by a set-processing command.

$Page

The current page number in a report.

$SetCount

The number of records found by the last FIND command.

External Programs

$Editor

The name of a text editor software package.

$Graphics

The name of a graphics software package.

$HelpFile

The name of a disk file containing online help.

Security

$ZGroupID

The application user’s Zim group identifier.

$ZUserID

The application user’s Zim user identifier.

System Variables Concerned with Windows

Last Event in the Current Window

ThisWindow is a data structure that provides information about the state of the application environment and of the current window at the time of the last event in that window. Each variable in the structure provides one item of information. The values of these variables are reset each time a window becomes the current window. An application program can assign a value to any of these variables at any time; however, the assigned value is overwritten the next time that another window becomes the current window.

ThisWindow.AltKey,
ThisWindow.CtrlKey,
ThisWindow.ShiftKey

The state of the Alt, Ctrl, and Shift keys at the time of the last event in the current window.

ThisWindow.EventName

The last event that occurred in the current window.

ThisWindow.EventTag

The identification tag of the object in which the last event in the current window occurred.

ThisWindow.EventType

The type of event that last occurred in the current window.

ThisWindow.KeyPressed

The key that, when pressed, caused the event that last occurred in the current window.

ThisWindow.MouseClick

If a mouse button accelerator caused the event that last occurred in the current window.

ThisWindow.ScrollingKey

If the accelerator that caused the event that last occurred was also a defined SCROLL key.

ThisWindow.WindowCol,
ThisWindow.WindowRow

The character column and character row position of the current window.

ThisWindow.WindowHeight,
ThisWindow.WindowWidth

The physical size of the current window in character rows and columns.

ThisWindow.WindowName,
ThisWindow.WindowNum,
ThisWindow.WindowTag

The current window

ThisWindow.WindowState

If the current window is maximized, minimized, or otherwise.

Miscellaneous

$WindowPSHeight, WindowPSWidth

The logical size of the current window in character rows and columns.

System Variables Concerned with Menus

Last Event in the Current Menu

ThisMenu is a data structure that provides information about the state of the software environment and of the current menu at the time of the last event in that menu. Each variable in the structure provides one item of information. The values of these variables are reset each time that FORM or MENU INPUT terminates. An application program can assign a value to any of these variables at any time; however, the assigned value is overwritten the next time that FORM or MENU INPUT terminates.

ThisMenu.Menuchanged

If any menu item in the current menu has been modified by the application use at the time of the last event in the current window.

ThisMenu.MenuItemNum,
ThisMenu.MenuItemTag

The selected item on the menu at the time of the last event in the current window.

ThisMenu.MenuNum
ThisMenu.MenuTag

The current menu at the time of the last event in the current window.

System Variables Concerned with Forms

Last Event in the Current Form/Display

ThisForm is a data structure that provides information about the state of the current form/display at the time of the last event in the current window. Each variable in the structure provides one item of information. The values of these variables are reset each time that FROM or MENU INPUT terminates, An application program can assign a value to any of these variables at any time; however, the assigned value is overwritten the next time that FORM or MENU INPUT terminates.

ThisForm.DisplayTag

The display that had focus at the time of the last event in the current window.

ThisForm.FieldChanged

A code indicated if the form field that had focus at the time of the last event in the current window was modified by the application user.

ThisForm.FFFieldNum,
ThisForm.FieldTag

The form field that had focus at the time of the last event in the current window.

ThisForm.FormChanged

A code indicating if any form field in the form or display had been modified by the application user at the time of the last event in the current window.

ThisForm.FormNum,
ThisForm.FormTag

The form that had focus at the time of the last event in the current window.

ThisForm.ReqError,
ThisForm.ReqFieldNum,
ThisForm.ReqFormNum,
ThisForm.ReqSubscript,
ThisForm.ReqTag

If all required form fields had values at the time of the last event in the current window.

ThisForm.Subscript

The instance of the form where focus was located at the time of the last event in the current window.

ThisForm.ValError,
ThisForm.ValFieldNum,
ThisForm.ValFormNum.
ThisForm.ValSubscript,
ThisForm.ValTag

If all form fields contained valid values at the time of the last event in the current window.

 

Evaluation Order of Functional Expressions

Functional expression are evaluated in stages. Evaluation starts with the most nested argument, and works outwards. If the innermost nest consists of several arguments, the arguments are evaluated from left to right. To change the order of evaluation, use parentheses to change the nesting level.

Consider the following example:

$minof($left(TelNo,3),var1+var2)

Because TelNo is the first argument of the innermost nest, the value of TelNo is determined first. If TelNo is a character-type field whose value is ‘416-555-1212’, then the expression is treated as if it reads

$minof($left(‘416-555-1212’,3),var1+var2)

The other arguments of the innermost nest are literals, so $left is now evaluated, returning the result ‘416’, a character string. The expression is now treated as if it reads

$minof(‘416’,var1+var2)

If the value of var1 is 400 and the value of var2 is 1, then the second argument of $minof evaluates to 401:

$minof(‘416’,401)

Because one of the operands of the $minof function is numeric, all the other operands must be converted. The character string ‘416’ is therefore converted to the number 416:

$minof(416,401)

Finally, the $minof function is applied, returning the result 401.

Rules of Precedence for Operators

Operator

Rule of Precedence

Conditional Operators

are evaluated first

NOT

NOT is evaluated first.

AND

AND is evaluated next.

OR, XOR

OR and XOR are evaluated last.

Note: Operators of equal precedence are evaluated from left to right in the expression.
Parentheses can be used to explicitly determine the order of evaluation, overriding the order described above. Each pair of parentheses can contain only one Boolean expression. For example:
not (Salary > 4500 xor LastName = ‘Smith’)
causes the XOR expression to be evaluated before the NOT.

Examples

Some examples of Boolean expressions are shown below:

DeptNum=’Sports’ and Salary > 45000 and LastName = ‘Smith’

Logically true when all three conditional expressions are true; otherwise, logically false.

LastName = ‘Allan’ or Firstname = ‘Allan’

Logically true when either of the conditional expressions is true; otherwise, logically false.

not Salary > 45000

Logically true when the conditional expression is logically false and vice versa.

not ProdCode between 542 and 863

Logically true when the conditional expression is logically false and vice versa.

not LastName in (‘Smith’, ‘Jones’)

Logically true when the conditional expression is logically false and vice versa.

not FirstName like ‘ Sm%’

Logically true when the conditional expression is logically false and vice versa.

About Boolean Expressions

Boolean expressions use Boolean operators to compare operands (typically, conditional expressions). When evaluated, Boolean expressions yield a logical result (true or false), depending on the nature of the Boolean operator and the values of the conditional expressions.

The standard rules of precedence for Boolean evaluation are used.

The software ceases to evaluate a Boolean expression as soon as the final result can be correctly predicted. For example, with OR, if the first conditional expression is logically true, then the Boolean expression must be logically true. The software does not bother to evaluate the remaining conditional expressions.

In the expression

LastName = 'Smith' or DeptNum = 'Sports'

if LastName = ‘Smith’ is logically true, then DeptNum = ‘Sports’ is not evaluated.

Note: Taking Boolean evaluation logic into account can be important to the functioning of an application program. For example, if any of the value expressions in the Boolean expression is written in the special assignment format, the assignment is not made if the portion of the Boolean expression containing the assignment is not evaluated.

Boolean Operators

OperatorMeaning
not exprNOTs the logic expression to the right. If the logic expression is true, the result of the Boolean expression is false; if the logic expression is false, the result of the Boolean expression is true.
expr and exprANDs two logic expressions (one to the left and one to the right). If both logic expressions are true, the result of the Boolean expression is true; otherwise, the Boolean expression is false.
expr or exprORs two logic expressions (one to the left and one to the right). If either (or both) of the logic expressions is (are) true, the result of the Boolean expression is true; if both of the logic expressions are false, the Boolean expression is false.
expr xor exprXORs two logic expressions (one to the left and one to the right). If either of the logic expressions is true, the result of the Boolean expression is true; if both of the logic expressions are true or if both are false, the Boolean expression is false.
en_CAEnglish