Understanding NLS (National Language Support) in Uniface with Informix: A Conceptual Deep Dive

When working with international applications that need to handle multiple character sets and languages, understanding National Language Support (NLS) becomes crucial.

In this article, we explore the conceptual foundations of NLS functionality in Uniface 10.4 when working with IBM Informix databases, focusing on the design decisions, trade-offs, and architectural considerations you need to understand.

What is NLS and Why Does It Matter?

National Language Support (NLS) is a database feature that enables applications to store, process, and display data in multiple languages and character sets.

In the context of Informix, NLS provides the ability to work with national characters beyond the standard ASCII character set.

For software applications incorporating NLS, this means avoiding dependencies on language-specific or culture-specific conventions for critical features like character classifications, comparison rules, code sets, and sort orders.

The Informix NLS Data Types: Nchar and Nvarchar

Informix introduces two specialized NLS data types: Nchar and Nvarchar. These are counterparts to the standard Char and Varchar types, but with important conceptual differences that affect how you design your database schema.

Key Conceptual Differences

Environment Dependency

The most fundamental characteristic of NLS data types is their environment dependency. Unlike their non-NLS counterparts, Nchar and Nvarchar can only be created, accessed, and manipulated in an NLS-enabled environment.

• You cannot use these types in legacy Informix installations without NLS support.
• Backward compatibility is not guaranteed.
• Migration strategies must account for environment configuration.

Collation and Sorting Behavior

One of the most significant conceptual differences lies in how data is evaluated when using NLS data types.

• Regular expression evaluation follows locale-specific rules.
• Sorting operations use local values instead of ASCII values.
• Index building respects cultural conventions.

This is particularly important for applications serving international users where alphabetical ordering differs from ASCII ordering. For example, in German, the character "ä" should sort near "a", not at the end of the alphabet as ASCII would dictate.

Performance Considerations

NLS data types are relatively expensive in terms of performance. The performance cost stems from:

• Additional processing for locale-aware operations.
• Potentially increased storage requirements for multi-byte characters.
• More complex comparison and indexing algorithms.

The Uniface Connector's Approach to NLS

The NLS Connector Option

Uniface provides an nls connector option that, when enabled, fundamentally changes how tables are created in Informix.

If this option is set and Informix NLS functionality is enabled:

• All Char fields become Nchar fields.
• All Varchar fields become Nvarchar fields.
• The transformation happens automatically at table creation time.

If the connector option is enabled but Informix NLS functionality is not properly configured, the database server will generate an error and table creation will fail.

The Packing Code Challenge

Uniface uses packing codes to map between Uniface data types and database-specific types. Currently, there are no dedicated packing codes for Nchar and Nvarchar. Instead, the connector performs substitution:

• Packing codes mapped to Char are substituted with Nchar.
• Packing codes mapped to Varchar are substituted with Nvarchar.

This substitution-based approach has an important limitation: you cannot create tables with mixed Char/Varchar and Nchar/Nvarchar fields through the connector alone.

Workaround for Mixed-Type Tables

If you need tables containing both standard and NLS character types, the Uniface documentation suggests a manual approach:

1. Use the Create Table facility in Uniface to generate a table creation script.
2. Manually modify the data types in the script (for example changing specific Char or Varchar columns to Nchar or Nvarchar).
3. Execute the modified script directly against the Informix database.

This workaround highlights a conceptual tension: the connector aims for simplicity and automation, but complex internationalization requirements sometimes demand manual intervention.

Character Set Limitations and European Language Support

An interesting aspect of Uniface's NLS implementation is its focus on single-byte, 8-bit character code sets. The documentation explicitly states that no special consideration is necessary for manipulating the NLS data types because they support only single-byte character sets.

Uniface supports European characters through the DEC ISO Latin-1 character set. This is a practical choice for many European languages but represents a limitation compared to full Unicode support, which Informix itself can provide when configured with Unicode locales.

This design decision suggests that Uniface's NLS implementation targets specific use cases rather than attempting to be a universal internationalization solution.

Network Considerations

An often-overlooked aspect of NLS is its interaction with network configurations. Informix products include integrated remote client/server communications, and NLS functionality is activated through environment variables.

This environment-based activation model means that:

• Configuration must be consistent across client and server.
• Network communication must preserve character encoding.
• A Uniface Router and Server setup can provide transparent network connectivity, but must run with the correct NLS-related environment variables.

The reliance on environment variables for NLS activation creates deployment considerations. You must ensure that environment variables are properly set on all systems involved in the data access chain, including application servers, Uniface Routers, and Informix database servers.

Design Trade-offs and Practical Implications

When to Use NLS Data Types

NLS data types are appropriate when:

• You need locale-aware sorting and comparison.
• The performance overhead is acceptable for the business value.
• Your character set requirements fit within the single-byte, 8-bit model used in your environment.
• All systems in your environment (development, test, production) are consistently configured for NLS.

When to Avoid NLS Data Types

Consider avoiding NLS types when:

• Performance is critical and you do not need locale-specific operations.
• You need backward compatibility with non-NLS systems or older Informix instances.
• Your data primarily uses ASCII characters and simple ordering is sufficient.
• You require full Unicode support beyond 8-bit character sets.

The Char/Varchar Hybrid Behavior

When NLS functionality is enabled, standard Char and Varchar columns can behave in a hybrid way: they may be stored and handled similarly to Nchar and Nvarchar, while sorting or other operations on foreign characters can still be done according to ASCII conventions unless additional NLS-related environment variables are set.

This creates a middle ground where you get some advantages of NLS-aware storage but still follow ASCII rules for ordering and comparisons unless you explicitly configure otherwise.

Common Pitfalls and How to Avoid Them

Configuration Mismatch

A common pitfall is enabling the Uniface nls connector option without properly configuring Informix NLS functionality. To avoid this:

• Verify that all required Informix NLS environment variables are set.
• Ensure that the database locale supports your required character sets.
• Align client, router, and server locales to avoid subtle data corruption.

Assuming Full Unicode Support

Do not assume that enabling NLS automatically gives you full Unicode support across the entire stack. Uniface's NLS handling, especially in older or specific configurations, focuses on single-byte character sets, which differs from full Unicode capabilities such as UTF-8 or UTF-16.

Performance Surprises

Always benchmark before committing to NLS types in production. The additional cost of locale-aware comparisons, sorting, and indexing can become visible at scale.

Measure the impact of NLS data types in realistic scenarios, such as large result sets, complex WHERE clauses relying on string comparisons, and frequent index rebuilds.

Mixed-Type Table Limitations

Remember that the Uniface connector cannot automatically create tables with both standard and NLS character fields. Plan your schema carefully or be prepared to use manual table creation scripts for advanced scenarios.

Conclusion

Understanding NLS in Uniface with Informix requires thinking beyond simple data type selection. It involves considering environment configuration, performance trade-offs, character set limitations, and the interaction between Uniface's connector architecture and Informix's native NLS capabilities.

The key takeaway is that NLS is not a universal solution but a specialized tool. Use it when you genuinely need locale-aware data operations, and understand the costs in terms of performance, complexity, and compatibility.

For many international applications, carefully evaluating whether you need true locale-aware operations or simply multi-language storage is essential. Often, a Unicode-capable configuration with standard data types can provide sufficient internationalization without the additional overhead and complexity of full NLS behavior.

About This Article

This article was created with the assistance of an AI system that helped organize and formulate complex technical concepts based on the Uniface 10.4 documentation and related database internationalization practices.

The goal is to transform dense technical documentation into conceptual understanding that helps developers make informed architectural decisions when working with Uniface and Informix in international contexts.