Variable-Length Packing Codes

Variable-length packing codes work with DBMSs that support a VARCHAR data type. They make it possible to store only the actual part of the field that is filled in, and not the trailing spaces that would be added for a fixed-length field.

For a field that is normally only partially filled, this can mean saving considerable disk space. For small fields, however, it might not save any space, because the database must store the length information in the field, which is not necessary for a fixed-length field.

Variable-length packing works only with DBMSs that support a VARCHAR data type. Most relational DBMSs support this feature. For DBMSs that do not support this format, a variable-length field will be mapped to a fixed-length field by the database connector. Therefore, you can still use these fields, although they do not save any disk space.

Categories of Variable-Length Fields

There are two categories of variable-length fields:

  • Limited—A field with interface VCm, where m is less than or equal to the maximum fixed length for the field in the database

    For example, the packing code VC10 represents a limited variable-length field and is the equivalent of a C10 field in which the data is stored without the trailing spaces.

  • Unlimited—A field where the packing code ends with an asterisk (*) or one that has a packing code VCn, where n is greater than the maximum fixed length for the field in the database

The following restrictions apply to unlimited variable-length fields in an entity:

  • You cannot use an unlimited variable-length field as a primary or candidate key, although it can be used as an index (provided your local DBMS allows using a VARCHAR field as an index).
  • You cannot mix unlimited variable-length fields with fixed-length fields, nor with limited variable-length fields. That is, in an entity definition, you must define all fixed fields first, then all limited variable-length fields, and finally all unlimited variable-length fields. This effectively splits up an entity into a fixed-length part and a variable-length part.
  • You cannot use a retrieve profile for unlimited variable-length fields.

Automatic Conversion From Fixed- to Variable-Length

Under certain circumstances, Uniface will automatically handle a fixed-sized field as a variable-length field. This will be the case when both:

  • The conceptual length of the fields is 33 or more
  • The underlying DBMS supports a VARCHAR data type

The assumption behind this is that large fields will hardly ever be filled completely, and, therefore, using variable-length storage will save disk space. The propagation from fixed to variable is done transparently by the connector for string data types with packing code C (character), R (raw), and U (TRX format). It does not affect the definitions in your model. If necessary, you can suppress this feature by using the ‘=’ prefix to the packing code. For instance, a field with packing code C50 will be stored as a VARCHAR(50), but a field with packing code =C50 field will be stored as CHAR(50).

For details (if any) about the mapping of fixed- to variable-length packing codes, see the connector documentation for your DBMS.

Related Topics