Indicates whether an index is to be maintained on the field.
As shown in the table below:
| Code | Meaning |
| No | (DEFAULT) The field is not to be indexed |
| Yes | The field is to be indexed |
| Unique | The field is to be indexed, and each value found in the field must be unique |
Index is ignored for fields that belong to documents.
A time stamp indicating when it was created
A time stamp indicating when it was created
The name of the owner of the database table on the database server if the table is not owned by the user or included in his or her schema.
The name of the owner of the database table on the database server
The name of the database table on the database server, if different than the EntitySet name. RemoteName is normally used when there is a naming incompatibility between Zim and the database server.
The name of the database table on the database server
Whether this relationship is defined to be per user.
“yes” or “no” (the default value is “no”).
The RelPerUser field only applies to Relationships with fields because there is no physical file to be handled.
Normally, Relationships with fields belong to the database and are managed by ZimServer. However, per user Relationships have these differences:
. They are handled by the current session and their information is lost after the session finishes;
. They are located in the $WorkPath directory;
. They don’t suffer any locks because they belong to the current user and no other users can access them;
. They don’t exist at the beginning of the session and must explicitly be created (or recreated) at any time by the application via the command INITIALIZE PERUSER. There is no need to keep a “storage” full of empty copies of all per user Relationships used by the Zim application.
In previous versions of Zim, per user Relationships were indicated with the “)” mark in the AREAS.ZIM file. This is no longer needed and any such entries will flagged with an error.
Whether this entity set is defined to be per user.
“yes” or “no” (the default value is “no”).
Normally, entity sets belong to the database and are managed by ZimServer. However, per user entity sets have these differences:
. They are handled by the current session and their information is lost after the session finishes;
. They are located in the $WorkPath directory;
. They don’t suffer any locks because they belong to the current user and no other users can access them;
. They don’t exist at the beginning of the session and must explicitly be created (or recreated) at any time by the application via the command INITIALIZE PERUSER. There is no need to keep a “storage” full of empty copies of all per user entity sets used by the Zim application.
In previous versions of Zim, per user entity sets were indicated with the “)” mark in the AREAS.ZIM file. This is no longer needed and any such entries will flagged with an error.
Indicates whether the field is a virtual field.
As shown in the table below:
Code | Meaning |
No | (DEFAULT) The field is a normal field |
Yes | The field is a virtual field |
A virtual field’s value is not stored in the database, but is computed dynamically, based on the expression entered into the field’s Default attribute.
A virtual field cannot be of type varchar or varalpha
Default
“Non-null required” status of a field. Indicates whether a value other than $Null is always required for the field in an ADD or CHANGE command.
As shown in the table below:
Code | Meaning |
No | (DEFAULT) The field need not be assigned a non-null value |
Yes | The field must always be assigned a non-null value, either explicitly or by the field’s default attribute (see Default) |
During an ADD command, if no value is required and none is assigned, the field’s value is set to its specified default value, which may be $Null.
Reqd is not used for fields that belong to documents.
Default
The name of an application directory (Directories); otherwise, the one application directory in which the associated object may exist.
An 18-character string, containing a valid object name
In Directories:
DirName is the name assigned to the directory.
In other Object Dictionary entity sets:
In any entity set, the principal object’s DirName must match the DirName of its owner.
If DirName is left blank, the object may exist in any number of application directories.
In DDDescriptions, DirName is where the object being described may be found.
In DisplayForms, DirName is where the owner-display of the associated form may be found.
ConstName, DDObjectName, DDOwnerName, DisplayName, DocName, EntName, FieldName, FormName, MenuName, OwnerName, RelName, RoleName, SetName, UserName, VarName
Index selectivity factors. Index selectivity factors used by Zim’s strategy optimizer.
A number from 0 to 1.000 (DEFAULT = 1.000)
The index selectivity factors are relevant for indexed fields only.
Each number represents the fraction of records that you would typically expect to retrieve using an indexed lookup with a particular operator or operators.
BWSel | selectivity factor for BETWEEN |
EQSel | selectivity factor for the equals (=) operator |
LGSel | selectivity factor for all other operators (i.e., less than (<), greater than (>), less than or equals (<=), greater than or equals (>=)) |
Values closer to 0 imply a very selective index, while values closer to 1 imply an index with poor selectivity. A value of 1.000 instructs Zim to use its internal selectivity factors.
Portuguese 
English