company logo

DataTypes - ODABA built-in data types

ODABA supports several built-in data types, which are listed below.

Enumarators overview

  • ASCII (17) - String values (ASCII 8 bit encoding)
  • BIT (11) - Bit strings
  • BLOB (15) - Binary large objects
  • CCHAR (14) - Coded character values
  • CHAR (1) - Character values
  • DATE (7) - Date values
  • DATETIME (13) - Timestamp
  • INT (3) - Signed integer or decimal number
  • LATIN1 (19) - String values (latin1 8 bit encoding)
  • LOCAL (21) - String values (local 8 bit encoding)
  • LOGICAL (9) - Boolean values
  • OGUID (2) - Global unique identity
  • REAL (12) - Float point number
  • STRING (10) - String values (latin1 8 bit encoding)
  • TIME (8) - Time value
  • UINT (4) - Unsigned integer or decimal number
  • UTF16 (16) - String value (UTF16 encoding)
  • UTF32 (20) - String value (UTF32 encoding)
  • UTF8 (18) - String value (UTF8 encoding)
  • VOID (6) - Unknown type

Enumerator details

  1. CHAR - Character values

    Character fields are defined with a maximum number of characters. Character fields are always padded with blanks. The maximum number of characters in a character field is limited to 2 GB. Character fields cannot be defined as reference type, but are valid for attributes, only.

    Character values are supposed to be ASCII values, i.e. character values must not contain special national or UTF8 encoded characters.

    Code: 1
    to list
  2. OGUID - Global unique identity

    Global unique identities are a system feature, which creates a world wide unique identity for an object when being created. Internally, GUIDs are represented in a 16 byte area. Externally, they are displayed as formatted string containing the id-version and the value displayed hexadecimal.

    Code: 2
    to list
  3. INT - Signed integer or decimal number

    ODABA considers decimal values the same way as binary values by defining a size and a precision. The size for an integer value defines the number of significant digits. The precision defines the number of positions behind the decimal point. Negative precision allow defining a decimal factor. Both, precision and positions describe the decimal presentation of the value, i.e. int(6,2) defines decimal numbers between -9999.99 and +9999.99. Nevertheless, integer values are stored as binary numbers.

    The storage size for integer numbers results from the defined size for the integer:

    • 1 - 3: 1 byte
    • 4 - 5: 2 byte
    • 6 - 10: 4 byte
    • 11 - 19: 8 byte

    In ODL one may, however, also define the standard names for integer values, which is converted automatically into size and precision.

    INT(5,2) defines numbers with three digits before the decimal point and two digits after.

    INT(5,-3) defines numbers with five digits that must be multiplied with 1000 (appending 3 zeros), i.e. you may store values between 1000 and 99999000 in the field.

    Code: 3
    to list
  4. UINT - Unsigned integer or decimal number

    ODABA considers decimal values the same way as integer values by defining a precision. The size for an integer value defines the number of significant digits. The precision defines the number of positions behind the decimal point. Negative precision allows defining a decimal factor.

    Unsigned values cannot store negative numbers. The storage size for integer numbers results from the defined size for the integer:

    • 1-2: 1 byte
    • 3-4: 2 byte
    • 5-10: 4 byte
    • 11-19: 8 byte
    Code: 4
    to list
  5. VOID - Unknown type

    Unknown types can be defined for references or transient fields (pointers), only. VOID references may refer to a collection or a single object instance with unknown type. The database will determine the instance type at run-time in this case.

    In OSI, VOID is considered as base class for any other type, i.e. each complex data type inherits from VOID. This allows defining generic expressions in the VOID class. You may also implement virtual expression in VOID, which can be overloaded in derived classes.

    Code: 6
    to list
  6. DATE - Date values

    Date fields allow storing date values. The size for a date field influences only the standard presentation of the date, i.e. the date to string conversion. Following size definitions are possible:

            8:     "2002-09-14"

            6,7: "02-09-14"

            4,5: "02-09"

            2,3: "02"

    Independent on the size the date is stored always as 4 byte integer value containing the number of days since 1870-01-01.

    ODABA supports different string representation for date:

            Standard: yyyy-mm-dd or yyyymmdd

            English:     mm/dd/yyyy

            German:     dd.mm.yyyy

    The type of date is determined from the separator used.

    Code: 7
    to list
  7. TIME - Time value

    Time fields allow storing time values from 0:00:00,00 up to 23:59:59,99. The size for a time field influences only the standard presentation of the time, i.e. the time to string conversion. Following size definitions are possible:

            8:      "23:59:59,99"

            6,7: "23:59:59"

            4,5: "23:59"

            2,3: "23"

    Independent on the size the time is stored always with 4 byte.

    Code: 8
    to list
  8. LOGICAL - Boolean values

    Boolean or LOGICAL values always have a fixed size 1, which relates to the binary value domain 0 for false or NO and 1 for true or YES.

    Code: 9
    to list
  9. STRING - String values (latin1 8 bit encoding)

    STRING data type is a text type name for generic string encoding. By default, STRING values are supposed to be Latin1 encoded data fields. By setting the DefaultEncoding option for the application, one may change the default encoding type for STRING values.

    Code: 10
    to list
  10. BIT - Bit strings

    Bit strings are supported for compatibility reasons. BIT types are supported within classes and transient fields. It is, however, not possible storing BIT type formats in the database.

    Code: 11
    to list
  11. REAL - Float point number

    REAL allows defining float point numbers. In ODL one may define "float" or "double" types, which result in REAL(7) and REAL(17). For REAL fields the size defines the number of digits for representing the field. Values up to 8 define a 4 byte float point number; values up to 17 define an 8 byte float point number.

    Code: 12
    to list
  12. DATETIME - Timestamp

    A date/time field (timestamp) is considered as basic data type even though it seems to be structured structured consisting of date and time. The size for the date time field will influence the presentation (to string conversion), but not the storage size. Timestamps with the maximum size of 22 are displayed as

    2002/09/14 23:59:59:99

    Lower size timestamps will cut the string at the end. Date and a time value can be accessed as structure members of the DATETIME structure.

    DATETIME last_update;

    last_update.date = Date().now();

    last_update.time = Time().now();

    Code: 13
    to list
  13. CCHAR - Coded character values

    Coded character fields are used when data stored in the database must be encrypted (e.g. when storing passwords in the database). The number of characters in a coded character field is limited to 256 characters. Coded fields cannot be defined as reference type, but are valid for attributes, only.

    Code: 14
    to list
  14. BLOB - Binary large objects

    Binary large objects are used to store complex data structures as pictures, videos or documents. Usually, BLOBs need special processes for interpreting the data within the BLOB. An extended feature in ODABA supports typed BLOBs and BLOB references, since it is often more convenient referring to BLOBs instead of storing them.

    Code: 15
    to list
  15. UTF16 - String value (UTF16 encoding)

    UTF16 stringproperties are Unicode fields with 16 bit encoding. The end of the string is indicated by a 16 bit 0 (0-terminated string).

    Defining variable string fields as attributes will always occupy storage with the defined size. In order to optimize storing large text instances, the property can be defined as reference. UTF16 type properties defined as reference are, from a conceptual point of view, attributes. Technical, however, they are considered as references and need to be defined as such.

    UTF16 fields are an ODABA specific extension.

    Code: 16
    to list
  16. ASCII - String values (ASCII 8 bit encoding)

    ASCII stringproperties are character fields with 8 bit encoding. The end of the string is indicated with a 0-character (0-terminated string).

    Defining variable string fields as attributes will always occupy storage with the defined size. In order to optimize storing large text instances, the property can be defined as reference. ASCII type properties defined as reference are, from a conceptual point of view, attributes. Technical, however, they are considered as references and need to be defined as such.

    ASCII fields are an ODABA specific extension.

    Code: 17
    to list
  17. UTF8 - String value (UTF8 encoding)

    UTF8 stringproperties are Unicode fields with 8 bit encoding. The end of the string is indicated with a 0-character (0-terminated string).

    Defining variable string fields as attributes will always occupy storage with the defined size. In order to optimize storing large text instances, the property can be defined as reference. UTF8 type properties defined as reference are, from a conceptual point of view, attributes. Technical, however, they are considered as references and need to be defined as such.

    UTF8 fields are an ODABA specific extension.

    Code: 18
    to list
  18. LATIN1 - String values (latin1 8 bit encoding)

    Latin1 stringproperties are Latin1 8 bit character fields with variable size. The end of the string is indicated with a 0-character (0-terminated string).

    Defining variable string fields as attributes will always occupy storage with the defined size. In order to optimize storing large text instances, the property can be defined as reference. LATIN1 or STRINGtype properties defined as reference (memo) are, from a conceptual point of view, attributes. Technical, however, they are considered as references and need to be defined as such.

    LATIN1 fields are an ODABA specific extension.

    Notes:

    STRING is the old text type name for LATIN1. Both might be used, but comparing data types, STRING is different from LATIN1. It is suggested using LATIN1 rather than STRING.

    Code: 19
    to list
  19. UTF32 - String value (UTF32 encoding)

    UTF32 stringproperties are Unicode fields with 32 bit encoding. The end of the string is indicated by a 32 bit 0 (0-terminated string).

    Defining variable string fields as attributes will always occupy storage with the defined size. In order to optimize storing large text instances, the property can be defined as reference. UTF32 type properties defined as reference are, from a conceptual point of view, attributes. Technical, however, they are considered as references and need to be defined as such.

    UTF32 fields are an ODABA specific extension.

    Code: 20
    to list
  20. LOCAL - String values (local 8 bit encoding)

    Local string properties are local 8 bit encoded character fields with variable size. The end of the string is indicated with a 0-character (0-terminated string).

    Defining variable string fields as attributes will always occupy storage of the defined size. In order to optimize storing large text instances, the property might be defined as reference. Base type properties defined as reference are, from a conceptual point of view, attributes. Technical, however, they are considered as references and need to be defined as such.

    LOCAL fields are an ODABA specific extension.

    Notes:

    With supporting different encoding types, MEMO became obsolete.

    Code: 21
    to list