JD Edwards table conversion: how it works and how to run one
how to run a JD Edwards table conversion manually
Also searched as
- JDE table conversion without full package build
- TC failed during package build EnterpriseOne
- how does JDE table conversion work
- EnterpriseOne table conversion design custom logic
Short answer
Table conversion (TC) is the EnterpriseOne mechanism that updates a table's physical structure and converts its existing data whenever a table's definition changes in Object Librarian, most commonly running automatically as part of a package build. Simple field additions or size changes convert automatically; more complex changes such as splitting a field or transforming values need a custom conversion routine attached to the table object.
Applies to: JD Edwards EnterpriseOne 9.1, 9.2, all tools releases
Trigger and check a table conversion
- 1Confirm the table's definition change (new column, changed length, changed data type) was checked in through OMW and is the correct spec version for the target path code.
- 2Decide whether the change needs a Full or Update package build, or whether it can go through as part of an ESU-delivered set of table changes.
- 3For a straightforward structural change, let the package build process run the conversion automatically - it detects table version differences and converts data as it deploys.
- 4For a change that cannot convert automatically (splitting one field into two, re-mapping coded values, merging data from another table), open the table object in Object Management Workbench and use its table conversion design tool to write the custom conversion logic.
- 5Test the conversion on a copy of the table or in a non-production environment first, since a conversion runs against live table data on the target environment during deployment.
- 6After the package deploys, check the table conversion log in the package's log folder on the deployment server to confirm each affected table converted successfully.
- 7If a conversion fails partway through, do not simply retry blind - check whether the table was locked by another process or whether the custom conversion logic threw an error on a specific row.
What table conversion actually does
Every EnterpriseOne table has a stored specification and an actual physical table on the database. When a developer changes that specification - adding a column, widening a field, changing a data type - the physical table and its existing rows are now out of sync with the new spec. Table conversion is the process that reconciles the two: it alters the physical table structure and converts the existing rows to match.
For simple changes (a new column with a default value, a longer character field) EnterpriseOne handles the conversion automatically without any developer intervention, generating the necessary DDL and data conversion logic itself during package build.
When you need a custom conversion
Automatic conversion cannot infer business logic. If a single field is being split into two new fields, if values need to be re-mapped against a different UDC, or if data from one table needs to populate a newly related table, the default field-level conversion has nothing to base that on. That is where a custom table conversion routine, attached to the table object in Object Management Workbench, comes in - it lets a developer write explicit logic for exactly how existing rows should be transformed.
This is a common step in larger customizations and in some ESU-delivered enhancements, and it is worth checking early whether a proposed table change is automatic or requires custom logic, since custom conversions need their own testing pass separate from the rest of the package.
Running a conversion outside a full package
Table conversions most commonly run as part of a package build, but a conversion for a single table does not require rebuilding an entire Full Package. A small Update Package that includes only the changed table (and anything dependent on it) triggers the same conversion logic on deployment, at a fraction of the build and deployment time of a Full Package.
This matters in environments where a Full Package build takes hours - isolating a single table structure change into a small Update Package is the fastest way to test and deploy the conversion without touching every other object in the path code.
Why conversions fail
The two most common failure modes are the table being locked by an interactive or batch process on the target environment during deployment, and a data value that the automatic or custom conversion logic cannot handle cleanly - for example a character value that does not fit a new numeric field, or a UDC value with no mapping defined in a custom conversion routine. Both show up in the table conversion log with the specific table and, for custom conversions, the row or condition that failed.
Common pitfalls
- !Assuming every table structure change converts automatically when a genuine data transformation needs custom conversion logic.
- !Running a conversion against a live production table without testing it against a copy first.
- !Rebuilding a Full Package to push one table change when a small Update Package would convert and deploy the same table far faster.
- !Not checking for locks or active sessions against the table before a conversion runs during deployment.
- !Skipping the table conversion log after deployment and assuming success just because the package build itself reported complete.
How an ERP-grounded AI assistant handles this
ERPray can be asked what a specific table's conversion history looked like across recent packages, or pull the exact wording of a table conversion log entry, without a developer hunting through deployment server log folders by hand. For anything that touches live production data, the conversion still has to be reviewed and approved by a developer who understands the business rule behind the change - ERPray surfaces the log, it does not decide the conversion logic.
Frequently asked questions
Does every table structure change need a custom conversion?
No. Adding a column, widening a field, or other straightforward structural changes convert automatically during package build. Custom conversion logic is only needed when the change requires business logic EnterpriseOne cannot infer on its own, such as splitting a field or remapping values.
Can I run a table conversion without a full package build?
Yes. An Update Package that includes only the changed table (and anything dependent on it) triggers the same conversion during deployment, and builds and deploys far faster than rebuilding a Full Package for the same change.
What happens if a table conversion fails halfway through?
Check the table conversion log in the package's log folder for the specific table and error. Common causes are the table being locked by another process, or a data value the conversion logic cannot handle. Resolve the underlying cause before resubmitting rather than retrying blind.
Where do I attach custom table conversion logic to a table?
Custom conversion routines are attached to the table object itself and opened through Object Management Workbench's table conversion design tool for that object, where a developer defines the transformation logic that runs during deployment.
Related
JDE package build failed: how to find the real cause
A package build (Full or Update) that ends in a failed or errored status on the deployment server does not explain itself in the Package Build Workbench screen. The real diagnostic detail is in the package's own log subdirectory on the deployment server, which holds a build log, a table conversion log, and per-object compile logs that pinpoint the actual failure.
Error fixJD Edwards business function (BSFN) errors: how to diagnose them
A BSFN error in EnterpriseOne means either the compiled function was not found for the current package build, or the function ran and threw an internal exception (often a null business view row, an unhandled C runtime error, or a failed table I/O). The fix path is different for each, so the first step is always determining which one you are facing from jde.log.
Error fixJDE UBE failed (status E): how to read jde.log and jdedebug.log
A UBE (batch report/program) that ends with status E in Work With Submitted Jobs tells you almost nothing on its own. The real error is in jde.log on the enterprise server, in the job's own PDF/log subdirectory (jdedebug.log if you turned on debug), and in the work directory for that job number under PrintQueue or the OS temp path.
How-toHow to set data selection and processing options in JD Edwards
Data selection controls which rows a UBE's underlying business view reads (a filter, stored per version in F9210/F9211), while processing options control how the program behaves once it has that data (a settings template stored per version in F983051/F983052). They are configured from the same Version Detail screen but are separate, unrelated mechanisms that new users routinely confuse.
Error fixJD Edwards: record is being used by another user (record reservation)
EnterpriseOne places a soft record reservation lock when a user opens a record for edit, tracked in the F00165 table, and releases it when the user saves, cancels, or the session ends cleanly. A stuck lock almost always means a session died abnormally (browser crash, network drop, kiosk timeout) without triggering the release, and it must be cleared by an admin, not by the original user retrying.
How-toHow to set up JD Edwards Orchestrator (step by step)
An EnterpriseOne orchestration chains one or more requests (form requests that drive an interactive application, or service requests that call a BSFN, business service, or SQL) plus optional rules and notifications, then exposes the whole thing as a callable REST endpoint via the AIS (Application Interface Services) server. The setup work happens in Orchestrator Studio, not the Fat Client.
AI for ERPAI for JD Edwards EnterpriseOne, Built on Orchestrator and AIS
Add AI to JD Edwards E1 9.2 using Orchestrator, AIS, and BSSV rather than screen-scraping. Ground a private LLM on F4211, F4111, and F0411 data.
AI for ERPOracle ERP AI Consulting: What a Partner Should Deliver
What to demand from an Oracle ERP AI consulting partner across EBS, JD Edwards, NetSuite, and Fusion Cloud: interface tables, APIs, and buyer questions.
Stuck on JD Edwards EnterpriseOne?
Talk to engineers who work inside JD Edwards EnterpriseOne every week, and who build private AI that answers these questions from your own ERP data.