Field Management on Informix in Uniface 10.4 🧩

#uniface #informix #database #segmentedfields

This article gives a simple overview of how Uniface 10.4 works with fields on Informix, especially segmented fields.

This post was created with the help of an AI assistant. 🤖

Field names in Uniface 10.4 ✍️

Uniface has clear and simple rules for field names when you work with Informix.

A field name can contain letters, numbers, and the underscore character.
The first character of a field name must always be a letter.
These rules keep your field names clean and make sure they work well with Informix.

Simple examples

Valid field names:

customer_name
address2
order_id
X123

These names start with a letter and only use letters, numbers, and underscore.

Invalid field names:

1st_name (starts with a number ❌)
customer-name (contains a dash ❌)
total€ (contains a special character ❌)

A good rule of thumb is: start with a letter, then use only letters, numbers, or underscore.

This also helps when you generate SQL or work with external tools that use your database schema.

Segmented fields on Informix 🧱

Informix supports segmented fields, for example large text or binary data.

In Uniface 10.4, these fields are handled in a special way by the Informix connector (the INF connector).

The most important points are:

The INF connector does not use stored procedures to read or modify segmented fields.
For tables that contain segmented fields, the INF connector does not create INSERT or UPDATE stored procedures that handle those segmented fields.
The connector may still create other stored procedures for the table, but these procedures do not retrieve or change segmented fields.

Instead, the connector uses dynamic SQL for operations on segmented fields:

For READ (select), WRITE (insert), and UPDATE requests on segmented fields, the INF connector builds SQL statements dynamically at runtime.
This gives more flexibility, because the logic is not fixed in a stored procedure in the database.

Why this behavior matters 💭

If you work on a system with Informix and large fields (for example BLOB or CLOB), this behavior is very important.

You cannot rely on stored procedures to see how segmented fields are handled, because they are not used for these fields.
When you debug performance or data issues, you have to remember that segmented fields are updated via dynamic SQL, not via stored procedures.
Database administrators might look for stored procedures that manage large columns and find nothing, which is normal in Uniface 10.4 for segmented fields.

Example scenario 📄

Imagine you have a table DOCUMENT with these columns:

DOC_ID (primary key, normal field)
TITLE (normal field)
CONTENT (segmented field, for example a long text or binary document)

In such a case (simplified example):

The INF connector can create stored procedures that work with normal fields like DOC_ID and TITLE.
It does not create INSERT or UPDATE stored procedures that read or modify the segmented field CONTENT.
When your Uniface component writes or updates CONTENT, the connector sends dynamic SQL statements to Informix instead of calling a stored procedure.

For you as a developer, this means:

Your Uniface code looks “normal”; you do not have to write special logic just because the field is segmented.
But when you trace or debug on the database, you must follow the dynamic SQL to understand how the segmented field is changed.

Practical tips for Uniface developers 🧪

Here are some simple tips when working with fields on Informix in Uniface 10.4:

Use clear field names that follow the rules (start with a letter, then letters/numbers/underscore).
Mark and document which fields in your model are segmented, so the whole team understands that stored procedures will not handle these fields.
When you talk with DBAs, explain that segmented fields are managed via dynamic SQL, not via stored procedures, so they know where to look when debugging.
If performance is a problem, check how often segmented fields are read or written, because large dynamic SQL operations can be expensive.

Simple “do and don’t” list

Do ✅:

customer_photo for an image field.
long_description for a big text field.
Keep names short but meaningful.

Don’t ❌:

1_photo (starts with a number).
customer-photo (dash is not allowed in this context).
beschreibung lang (spaces or special characters will cause problems).

Conclusion 💡

Uniface 10.4 uses simple and strict naming rules for fields on Informix, which helps to avoid many problems in your database layer.

Segmented fields are a special case: they are not handled by INSERT and UPDATE stored procedures, but by dynamic SQL created by the INF connector at runtime.

If you understand this behavior, it becomes much easier to debug, tune performance, and collaborate with your database team. 🧠