Infor LN DAL Out of Sync After a Custom Field: Cause and Fix
infor ln dal out of sync error after adding custom field
Also searched as
- infor ln field not found in table after change
- baan table administration inconsistent error
- infor ln custom field not showing in session
- infor ln dal regeneration after ddl change
Short answer
Infor LN throws a DAL, or table, out of sync error, or simply drops a new custom field silently, when a table's dictionary definition is changed but the generated DAL and dependent forms are not regenerated afterward. Running the standard sequence, table compile, DAL generation, then session/form compile, in Tools > Development after every dictionary change resolves it. Skipping any one of the three steps is what causes the mismatch.
Applies to: Infor LN 10.x development and customization tools (Table Maintenance, DAL generation); applies to custom tables and standard tables extended with custom or free fields
Rebuild a table's generated layers after a field change
- 1Confirm the field was added correctly in Tools > Development > Tables, including data type, length and default value.
- 2Recompile the table definition itself so the physical database column and the LN dictionary definition agree; this step generates the actual DDL against the database.
- 3Regenerate the table's DAL, the generated code layer LN uses at runtime to read and write the table, so it recognizes the new field.
- 4Recompile any sessions, forms or reports that reference the table, since a form built against the old DAL will not show or accept the new field even after the DAL itself is regenerated.
- 5If the field was added to a standard (non-custom) table, confirm it went through the supported free or custom field mechanism rather than a direct database ALTER TABLE, since unsupported direct changes will not survive the next patch or upgrade.
- 6Clear cached metadata on the application server, or restart the relevant service, so running sessions pick up the regenerated DAL.
- 7Test the change in a single session in a non-production company before rolling the regeneration out to all users.
Why LN needs three separate steps
Infor LN's 4GL architecture separates the table's dictionary definition, the generated DAL that mediates database access, and the compiled sessions and forms that call the DAL. A change made only in the dictionary does not automatically propagate to the DAL or to any form, which is why a field can exist in the table and still be invisible or throw an inconsistency error at runtime.
This is different from tools where adding a database column makes it immediately usable everywhere. LN's approach gives more control over what is exposed and where, but it means every dictionary change needs the corresponding regeneration and recompile steps, in order, before it actually works end to end.
What out of sync actually means
The error, or its common variants such as a field simply not appearing or a session refusing to save with a generic inconsistency message, means the compiled DAL's view of the table's columns does not match either the current dictionary definition or the physical database table. Any one of the three (dictionary, DAL, database) getting ahead of the other two produces this symptom.
It most often happens when a developer adds a field, tests the dictionary change, gets interrupted, and forgets to run the DAL regeneration and form compile before handing off the change, or when a transport moves the dictionary change to another environment without also moving the generated code with it.
Custom fields versus modifying standard tables
LN provides supported custom and free fields specifically so customizations survive patching and upgrades. Adding a genuinely new column directly to a standard table with a database tool, bypassing LN's table maintenance, is unsupported: the generated code has no knowledge of the column, and the next patch or upgrade can silently conflict with or drop it.
If the business need is a new attribute on a standard table, use the free or custom field mechanism, or a proper table extension for sites with development licensing, rather than a manual ALTER TABLE, even though the manual route looks faster in the moment.
Common pitfalls
- !Adding the field to the dictionary and stopping there, assuming the DAL regenerates automatically.
- !Regenerating the DAL but not recompiling the forms and reports that reference the table, so users still see the old layout.
- !Making the change directly against the database with SQL instead of through LN's table maintenance tools.
- !Transporting a dictionary change to another environment without also transporting the regenerated DAL and compiled objects.
- !Skipping a metadata refresh or application server restart, so active sessions keep using the cached, pre-change DAL.
How an ERP-grounded AI assistant handles this
For LN developers, a grounded coding assistant applying Netray's customization pattern to LN can check whether a table, its DAL and its dependent sessions are actually in sync before a developer hits the error at all, by comparing dictionary metadata against the last generated DAL timestamp. It can also produce the standard regenerate-and-recompile checklist for a specific table change so nothing in the three-step sequence gets skipped during a rushed fix.
Frequently asked questions
Which session regenerates the DAL in Infor LN?
DAL generation is triggered from the table's compile or generate action in Tools > Development > Tables, or through a dedicated DAL generation tool depending on your LN version. The exact menu path varies slightly by version, but the sequence, dictionary compile, then DAL generation, then form compile, is consistent.
Can I add a custom field without any coding?
Yes. LN's free and custom field mechanism lets you add fields to many standard tables through table maintenance without writing 4GL code, and the standard regeneration steps make them usable on forms. Coding is only needed for custom business logic tied to the field, such as validation or calculations.
Why does the field work for me but not for other users?
This usually means the DAL and dictionary were regenerated, but other users' sessions are still holding the old cached metadata, or the change has not been transported to the environment or company those users work in. A session restart often resolves it for individual users.
Does having many custom fields hurt performance?
A modest number of custom fields has negligible impact. Very large numbers of free fields on a heavily used transaction table can add overhead to DAL calls and reports, so it is worth periodically reviewing whether older custom fields are still in use before adding more.
Related
Infor LN bshell Process Stuck at 100% CPU: How to Diagnose and Fix It
A bshell process pinned at 100% CPU on the Infor LN application server almost always means one session is stuck in a 4GL loop, scanning an unindexed table, or waiting on a database lock. End the session from the Sessions Monitor first, then kill the OS process only if that fails, and check for a blocking database transaction before assuming it is a bug.
Error fixInfor LN Not Authorized to Run This Session: How to Fix It
Infor LN refuses to open a session with a not authorized message when the logged-in user's assigned role does not include that session, or when the session is blocked for the company they are logged into. Grant the session through Common > Authorization Management > Roles, or check the user's role and company context, and the session opens on retry. In most cases this is a permissions configuration issue, not a bug.
Error fixInfor LN Jobs Stuck in Active or Waiting: Fix the Job Daemon
Infor LN background jobs, reports, batch processes and print jobs, get stuck in Active or Waiting status when the job daemon on the enterprise server has stopped or lost its connection, or when a prior job crashed without releasing its status. Restart the job daemon and reset the stuck job's status through the Jobs session, and the queue resumes. A daemon that keeps stopping usually points to a memory, license or database connectivity problem on the server.
Error fixInfor LN Reports Stuck in the Print Queue: Device and Spooler Fix
Infor LN reports and forms stay queued and never reach the printer when the target device definition points to a printer that is offline, or the print listener on the print server has stopped. Check the device's status in Common > Printing > Devices, confirm the underlying OS printer is reachable, and restart the print listener if jobs remain queued after the printer itself is fixed. Most cases trace back to a genuinely offline printer, not an LN bug.
AdvancedHow to extend business logic in Infor LN with DAL2
DAL2 lets you add custom validation, defaulting and calculation logic to Infor LN Enterprise Edition tables by writing a Java business logic handler class and registering it against a table event, without editing the standard DAL. Because the logic sits in your own package rather than inside Infor's base code, it survives upgrades that would otherwise overwrite a direct DAL change.
AdvancedHow to create a custom session in Infor LN Studio
Infor LN Studio's session designer generates a new maintenance, overview or detail session from a table definition, then lets you arrange fields, attach DAL2 validation, and wire menu access, all inside a custom package so the session survives upgrades. Building on a custom table gives the lowest upgrade risk; extending a standard table needs more care and re-testing after every release.
AI for ERPAI for Infor LN: Sessions, BODs, and Engineer-to-Order Work
Add grounded AI to Infor LN 10.x or CloudSuite: natural-language answers over sessions and BODs, agents for project and engineer-to-order work, on-prem options.
AI for ERPAI for Legacy Baan IV/V: Capture the Knowledge Before It Walks Out the Door
Use AI to capture knowledge from ageing Baan IV/V systems, document undocumented customisations, and de-risk a future migration to LN or CloudSuite.
Stuck on Infor LN (Baan ERP)?
Talk to engineers who work inside Infor LN (Baan ERP) every week, and who build private AI that answers these questions from your own ERP data.