DDOConstraints - DataDictionary

Used to query array of DataFlex constraints

Type: Function

Return Data Type: tConstraintDef

Parameters: None

Return Value

Array of tConstraintDef. See Description text for details.


Syntax
Function DDOConstraints Returns tConstraintDef[]

Call: Get DDOConstraints to tConstraintDefArrayVariable


Description

tConstraintDef[] Constraints
Get DDOConstraints of  hoDD to Constraints


You can query the array of DataFlex constraints by calling Get DDOConstraints of the DDO after the constraints have been rebuilt. This returns an array of tConstraintDef types. A tConstraintDef type contains all of the information that can be provided for a single constraint. It is defined as follows:

// Struct used to DDOConstraints to return current constraints in an array
Struct tConstraintDef
    Integer eType
    Integer eMode
    Integer iFile
    Integer iField
    String sValue
    Integer iOtherFile
    Integer iOtherField
End_Struct

MatchesJumpIn = matches which is capable of a jump in, e.g., "A*"

eType - Constraint Type

eType determines the type of constraint and can be one of the following values:

CONST_VALUE (0)

Constrain Customer.Name GT "J"

The DataDictionary Object (DDO) filters the value of iFile and iField based on the comparison mode (eMode) and the value in sValue. This is defined with something like "Constrain File.field GT SomeValue". See eMode for information about the comparison modes. The value in sValue is evaluated when the Constrain command is executed (which occurs when Rebuild_Constraints calls OnConstrain). Therefore, this value can be a constant, a variable or an expression. Its value is determined when the constraint is built and not when the record is found.

CONST_CHILD (1)

Set Constrain_File to Customer.File_Number

The DDO relates to a parent DDO. This is usually defined with the "Set Constrain_File" interface. If can also be defined using the "Constrain File relates to ParentFile" constrain command. When this type is defined, the child table and relating from column is stored in iFile and iField and the related to parent table and column is stored in iOtherFile and iOtherField. Note that if no existing relationship is found between the two files, this constraint will not even get added to the array of constraints.

CONST_FIELD (2)

Constrain Customer.ID EQ Region.ID

This is similar to CONST_VALUE, except the value being compared will be another table.column value. This is usually defined with something like "Constrain MyFile.MyField GT SomeOtherTable.SomeColumn". The members iFile and iField define the value on the left and iOtherFile and iOtherField define the value on the right. Unlike CONST_VALUE, the value on the right is not known until the record is found.

When the record is found, the runtime will determine if the record for the right side first requires a relate. This will determine if the comparison is made before or after a relate.

CONST_EXP (3)

Constrain Customer as (LowerCase(Left(Customer.name,1)="a"))

This is used with 'Constrain As' constraints. Typically, this is defined with something like "Constrain File as (Expression)". The runtime can provide no additional useful information about this expression, so none of the other struct members convey any useful information.

CONST_RELATES (4)

This is a legacy runtime value that should never appear. It is the same as CONST_CHILD.


eType - Constraint Find Modes


eType is the find comparison mode and is used with CONST_VALUE and CONST_FIELD.

Values are:

ConstantMeaning
CONST_LT ( 0)Constrain Customer.sName LT sValue
CONST_LE (1)Constrain Customer.sName LE sValue
CONST_EQ (2)Constrain Customer.sName EQ sValue
CONST_GE (3)Constrain Customer.sName GE sValue
CONST_GT (4)Constrain Customer.sName GT sValue
CONST_NE (5)Constrain Customer.sName NE sValue
CONST_Matches ( 6)Constrain Customer.sName matches "?A*"
CONST_Contains (7)Constrain Customer.sName contains sValue
CONST_MatchesJumpIn (9)Constrain Customer.sName matches "A*"


The different between Matches and MatchesJumpIn is determined by the right side value and whether it is structured in such a way that a jump can be performed. For example, "Dat*" can be used for jump in while "?Dat*" cannot.

There is no actual 'Between' constraint operator. When you use 'Between', two constraints are added the array, one for GE and one for LE.

Each DDO has its own array of constraints. When constraints are inherited, the DDO that has inherited the constraints will contain an array of constraints that includes the inherited constraints.

Use of DDOConstraints is an advanced and rarely needed technique. If you want to see how this can be used study the code and the results in the Data Dictionary Inspector (DD_Debug.pkg).