Skip to content
IFS Wire

Community · Question

Random boolean and decode errors on IFS Applications 10 TEST and UAT clones until the language cache is refreshed

Asked by IFS Wire DeskEditorial · 10 Nov 2026 · 0 views

Type:
Technical
Product:
IFS Applications
Version:
10 UPD27

Sourced from IFS Community · original thread

0

An IFS Applications 10 (UPD27, IEE client) installation runs three databases: TEST, UAT and PROD. TEST and UAT share one database server, PROD runs on a separate server, and TEST and UAT are copies of PROD.

On TEST and UAT only, users intermittently and with no obvious pattern start receiving unexpected error messages. In one case a standard window raises an error saying a boolean must have a value, even though that field is not shown on the screen. Investigation showed that the view behind the window contains a boolean column that ends up empty, because the decode function cannot derive TRUE/FALSE from the underlying _db field.

Running a language cache refresh makes the errors go away. Why does this happen, how can it be prevented, and why are only TEST and UAT affected while PROD is not?

Technical details Product: IFS Applications 10 UPD27, IEE client. Environments: TEST and UAT on the same database server, PROD on a separate server; TEST and UAT are clones of PROD. Symptom: boolean must have a value error in a standard window; the view's decode of the _db field returns no TRUE/FALSE value. Workaround observed: language cache refresh.

Any attachments are visible to signed-in members.

1 answer

0

✓ Accepted answer

Suggested explanation and approach (from an IFS employee reply; the poster has not yet confirmed it):

Likely cause: the symptoms fit a situation where the language dictionary and the domain PROG–DB value lists are out of sync. This tends to happen on non-production clones that receive extra deployments and where the cache refresh was incomplete. Refresh Language Cache clears the symptom because it rebuilds those lists.

Suggested routine after every clone from PROD and after every deployment to TEST or UAT:

  1. Run Refresh Language Cache for all languages in use.
  2. Run Refresh Server Cache, first Dictionary and then Reference.
  3. Restart the application server.
  4. Have users start new sessions.
  5. Schedule a periodic language refresh on TEST and UAT, and check the batch logs for language refreshes that failed or only partly completed (custom LUs can break the component refresh).

Why PROD stays clean, according to the reply: on PROD the code and caches usually stay aligned, while TEST and UAT drift unless the post-clone and post-deploy sequence is automated.

Confirmed: running a language cache refresh removes the errors (reported by the poster). Not yet confirmed: the root cause and whether the preventive routine stops the errors from returning.

Prerequisites and limitations Reported on IFS Applications 10 UPD27 with the IEE client. Requires administrator rights to run Refresh Language Cache and Refresh Server Cache and to restart the application server. The root-cause explanation and preventive sequence are a suggestion from one reply and have not been confirmed by the poster. Custom LUs can cause the language refresh to fail or complete only partly, so check the batch logs.

Sourced from IFS Community · original thread

Answered by IFS Wire DeskEditorial · 10 Nov 2026