1 1 1 Field Type Considerations

1.1.1 Field Type Considerations

Field Definitions

Field types 1.1.2 Alpha, 1.1.7 Packed, and 1.1.8 Signed can be used in all partitions.
Field types 1.1.11 Date, 1.1.12 Time, 1.1.13 DateTime, 1.1.14 Binary, 1.1.15 VarBinary, 1.1.3 String, 1.1.4 NVarChar, 1.1.6 NChar, 1.1.5 Char, 1.1.9 Integer, 1.1.10 Float, 1.1.17 BLOB, 1.1.18 CLOB and 1.1.19 Boolean must be used in an RDMLX Enabled Partition. Refer to RDML and RDMLX Partition Concepts in the Administrator Guide for details about these partition differences.
Packed, Signed and Integers allow Edit Codes and Edit Words. No other field types support Edit Codes or Edit Words.
Keyboard Shift Blanks is the only valid value for Binary, VarBinary, Date, Time, DateTime, Integer, Float, NVarChar, NChar, BLOB and Boolean.
In an RDMLX partition, a field that is defined by a reference field must not have different attributes to the reference field, regardless of the *IMPREFFLDNOPROP flag in the system definitions.
ASQN attribute (see Common Attributes in 1.2.17 Input Attributes) will be enabled by default for new fields of types Date, Time, DateTime, Binary, VarBinary, BLOB, and CLOB.

Field Usage in LANSA

LANSA has implemented strong typing for all field types.
Alpha, String and Char are all classed as String types and are valid for LANSA arguments of type 'A'.
Packed, Signed, Float and Integer are classed as Numbers and so are valid for LANSA arguments of type 'N'.
All other types like Date, DateTime and BLOB are classed as their own type and are not valid for either a type 'A', or type 'N'.
Use of Hex 00 is not supported by LANSA in Alpha, String, Char, NVarChar and NChar fields. The behavior will vary depending on what platform you are on and the database you write the data to. The use of hex 00 in Alpha working fields where overlays are used may have a valid purpose in RDML on IBM i, but it is up to the you to ensure that the LANSA behavior meets the needs of the application on all platforms and databases where the application may run.
Field types have a default property, usually .Value, and additional properties as required. For a Date field #MyDate, the following examples all have an identical meaning:

Define Field(#MyDate) Type(*DATE)

Change #MyDate To(1972-03-04)

Set #MyDate Value(1972-03-04)

#MyDate.Value := "1972-03-04"
Rather than the default property .Value, fields of type BLOB and CLOB have a default property called .FileName to clearly indicate that changing the "value" of the field is actually changing its default property which is a file name property.
Fields that are SQL-nullable can be tested with *IS or *ISNOT *SQLNULL, and also have an intrinsic property called .IsSqlNull. This can be used to determine the current state of the field. For example:

If (#Std_Num.IsSqlNull)

If (#Std_Num *ISNOT *SqlNull)

If ((*Not #Std_Num.IsSqlNull) *AndIf (#Std_Num > 45.00))

If ( ([your expression] *IS *SqlNull )

Built-In Function Argument/Return Value Types

Refer to BIF Function Rules for information.

Tips & Techniques

LANSA has implemented strong typing for all field types. For example, a Built-In Function that allows an Alpha will also support String. It will not allow a DateTime. To use a DateTime, you simply use #MyDateTim.asString, explicitly stating that you want to use the string representation.
If you are using RDML Partitions, you may wish to refer to the LANSA for i User Guide. This documentation has been written for development using RDML Partitions only.
Some field types such as 1.1.10 Float are primarily supported in LANSA for use with Other Files and are not recommended for use in business applications. It is recommended that you use 1.1.9 Integer or 1.1.7 Packed fields for the majority of your numeric data, and 1.1.8 Signed is also recommended for RDML partitions.
Character data can be stored in 1.1.2 Alpha, 1.1.3 String, 1.1.5 Char, 1.1.4 NVarChar and 1.1.6 NChar type fields. Where possible, use of 1.1.2 Alpha fields is recommended.
Select the vendor specific DBMS you are targeting and be sure to review all warnings when creating/editing files to ensure that there are no problems supporting a specific field range for the selected DBMS.

Platform Considerations

When creating a LANSA file, LANSA field types are converted to specific DBMS Data types supported by each vendor. For example, an Integer field (depending upon its length) might be implemented as a TINYINT, SMALLINT, INTEGER, BIGINT, NUMBER(3), NUMBER(5), or other type, depending upon the specific vendor DBMS layer supported. The file x_dbmenv.dat controls this behavior though it must not be modified.
In some cases, a particular vendor's DBMS may not be able to handle the full length of a field because the length of data available in LANSA exceeds the length available in the vendor's database. It is possible to select the target DBMS system and warnings will be displayed where the field may not be preserved exactly. In these cases, the data will either be truncated, or rejected. For example, if you define a DateTime of length 29, Oracle supports storing the full 9 decimal places. Other DBMSs might automatically truncate data to 0, 3, or 6 decimal places.

Also See