# JD Edwards table conversion: how it works and how to run one > Source: https://netray.co/erp-help/jde-table-conversion-how-to > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind how-to ## System jd-edwards ## Erp JD Edwards EnterpriseOne ## Module CNC / Table Conversion ## Query how to run a JD Edwards table conversion manually ## Alternate Queries - JDE table conversion without full package build - TC failed during package build EnterpriseOne - how does JDE table conversion work - JDE table - what is a table conversion in JD Edwards - EnterpriseOne table conversion design custom logic ## Applies To JD Edwards EnterpriseOne 9.1, 9.2, all tools releases ## Steps ### Trigger and check a table conversion **Items:** Confirm 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. Decide 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. For a straightforward structural change, let the package build process run the conversion automatically - it detects table version differences and converts data as it deploys. For 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. Test 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. After 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. If 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. ## Sections ### What table conversion actually does **Body:** 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 **Body:** 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 **Body:** 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### Does every table structure change need a custom conversion? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms JDE table conversion, JD Edwards TC log, EnterpriseOne table conversion design, JDE custom table conversion, table conversion package build, JD Edwards data dictionary change conversion, table conversion failed locked table, JDE update package table conversion --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json