Franz

Posted on Dec 23

Uniface 10.4 + Informix: Simple Guide to Data Packing 📦

#database #programming #beginners #tutorial

🤖 This blog post was created with the help of an AI assistant and is based on the Uniface 10.4 documentation about “Informix Data Packing”.

When you use Uniface 10.4 with an Informix database, every field in your model has a packing code. This packing code tells Informix how the data is stored in the database. 😊

In this article, you see how Uniface packing codes map to Informix storage formats, in simple language and with small examples. This can help you avoid strange data problems when you design or debug your application. 💡

What is data packing?

In Uniface, each field has a data type and a packing code, for example C10 or I4. The packing code controls how the data is stored physically in the Informix table (for example as CHAR, VARCHAR, DECIMAL or DATE).

The Informix connector uses a fixed mapping from the Uniface packing code to the Informix storage format. This means that the same packing code always results in the same Informix data type.

Very small example

C10 in Uniface → stored as CHAR(10) in Informix.
I4 in Uniface → stored as INTEGER in Informix.
D in Uniface → stored as DATE in Informix.

Once the table is created in Informix, this mapping is fixed for that column unless you change the table definition with SQL. So choosing the right packing code is important already in the Uniface model.

Character and text fields 📝

Many Uniface packing codes become simple character types in Informix. These are used for names, codes, flags and other text data that is not extremely large.

B, B1-B5 → stored as CHAR in Informix (for example for boolean-like fields stored as Y/N or 0/1).
C1-C* → stored as CHAR (fixed-length character fields).
R1-R* → stored as CHAR (often used for raw codes).
(S)A1-A9 → stored as CHAR (short strings).
(S)A11-A40 → stored as CHAR (longer strings).
T, T1-T2 → stored as CHAR (small text or time-related codes).
U1-U* → stored as CHAR (Unicode string handled as character data by the connector).
VC1-VC255, VR1-VR255, VU1-VU255 → stored as VARCHAR (variable-length text).
VC256-VC*, VR256-VR*, VU256-VU* → stored as CHAR (because of size limits in the Informix driver).

Example: customer name

Imagine a field CUSTOMER.NAME defined as C40 in Uniface. The Informix connector will create this as CHAR(40) in the database.

If you change it later to VC40, Uniface would map it to VARCHAR(40), which can save space but may behave differently in indexes and comparisons. So plan your character packing codes with your DBA rules in mind.

Numbers and money 💰

For numeric fields, the Uniface packing code controls whether Informix uses INTEGER, SMALLINT, DECIMAL, FLOAT or MONEY. This is important for precision and performance.

I1-I2 → SMALLINT (small integers).
I3-I4 → INTEGER (normal integers, for example IDs or counters).
I8 → FLOAT (large numeric values stored as floating point).
F → DECIMAL (fixed-point numeric, generic F).
F4 → REAL (4-byte floating point).
F8 → FLOAT (8-byte floating point).
M1-M4 → MONEY (monetary values).
N1-N32 → DECIMAL (numeric with different sizes and precision).
(N)C1-32 → DECIMAL (numeric values packed with a C packing, but stored as decimal).
O1-O32, P1-P16, Q1-Q16 → DECIMAL (different decimal ranges and precisions).

Example: invoice amount

For an invoice amount, a typical choice in Uniface is M2 (money with 2 decimals). The Informix column will then be of type MONEY, which keeps the decimal places stable and is easy to sum in SQL.

If you used a floating type like F8 instead, Informix would store it as FLOAT, which can introduce rounding issues for financial calculations. So for prices and totals, it is safer to use M* or N* (decimal) instead of FLOAT.

Dates and times ⏰

Date and time fields have special mappings because Informix has dedicated date and datetime types. Using the correct packing code here makes your queries simpler and more efficient.

D, D1-D11 → DATE (calendar date without time).
E, E1-E8, E10 → DATETIME YEAR TO SECOND (full date and time down to seconds).
T3 → DATETIME YEAR TO SECOND (time-related packing that maps to datetime).

Example: order date vs. timestamp

For an ORDER_DATE field, a simple D is often enough and becomes DATE in Informix. For an audit field like LAST_UPDATE, you can use E so that Informix stores DATETIME YEAR TO SECOND.

This way you can easily select all rows from today or sort by the exact update time in SQL. It also keeps the storage compact and index-friendly.

Serial, byte and text fields 📂

Some Uniface packings are used for special Informix types like serial numbers, byte data and text data. These are important for technical IDs, blobs and large documentation fields.

(S)A10 → SERIAL (auto-increment integer, often used as technical primary key).
SR1-SR* → BYTE (binary data, for example PDF or image stored as blob).
SC1-SC* → TEXT (large text stored as a TEXT blob).
SU1-SU* → TEXT (Unicode text stored in a TEXT-like way by the connector).

Example: document storage

If you have a field DOCUMENT.FILE_CONTENT with packing SR1, Informix will store it as BYTE. This is good for binary files like PDFs.

For a field DOCUMENT.LONG_COMMENT with packing SC1, Informix will store it as TEXT. This is better for long user comments or descriptions that can be larger than normal VARCHAR limits.

Why this mapping matters in real projects 🧠

The mapping between Uniface packing codes and Informix storage formats is not just a technical detail. It affects how indexes work, how much disk space you use and how easy it is to write SQL queries.

If you choose a CHAR packing for a field that changes a lot in length, your table may waste space and become slower.
If you choose a floating type (F4, F8, I8) for monetary values, you may get rounding problems in reports.
If you use TEXT or BYTE for fields that you often filter in WHERE clauses, you may not be able to index them easily.

A good practice is to create a small test table where you define one column for each packing code that you plan to use. Then you can check the real Informix types with tools like dbschema or your favorite database browser and adjust your Uniface model before you go to production. ✅

Uniface 10.4 and Informix give you a flexible and powerful combination for business applications. When you understand how packing codes map to Informix storage formats, you can design models that are both safe and efficient. 🚀

DEV Community