# JDE package build failed: how to find the real cause > Source: https://netray.co/erp-help/jde-package-build-failed-how-to-fix > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer 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. ## Kind error ## System jd-edwards ## Erp JD Edwards EnterpriseOne ## Module CNC / Package Build and Deployment ## Query JD Edwards package build failed, how to find the cause ## Alternate Queries - JDE full package build fails at table conversion - EnterpriseOne package build error, where is the log - JDE update package build stuck or failed - package deployment failed EnterpriseOne workstation ## Applies To JD Edwards EnterpriseOne 9.1, 9.2, all tools releases (Windows, IBM i, and Linux/AIX deployment servers) ## Steps ### Find and read the package build failure **Items:** In the Package Build Workbench, open the package definition and check the build status and the build machine it ran on (deployment server name). Log on to that deployment server and locate the package's share, typically under the path code, e.g. \\deploymentserver\B9\PackageName. Open the log subdirectory under the package name and look for the build log first - it lists each major phase (spec merge, table conversion, business function compile, table/index build) with pass or fail markers. If the failure is in the table conversion phase, open the table conversion log for that package and search for the specific table (F number) that failed. If the failure is in the compile phase, check for a separate compile errors log - this usually points to a specific custom C business function or a missing include file. Confirm the OMW project for anything included in the package was actually checked in and transferred to the correct path code before the build started. Check available disk space on the deployment server share - package builds fail silently partway through when the drive fills up mid-build. If a table conversion failed because the table was in use, confirm no interactive or batch job had that table open on the target environment during the build window, then resubmit. For a Full Package, if only one object caused the failure, consider whether a smaller Update Package targeting just that object is faster to debug than rebuilding the whole Full Package again. ## Sections ### Why the build status alone is not enough **Body:** Package Build Workbench reflects a summary status written back by the build process on the deployment server - it was never designed to stream detailed compiler or table conversion output back to the client. A status of failed or errors just tells you something in one of several build phases did not complete cleanly. The build itself runs unattended on the deployment server, driven by the package definition (which environment, which path code, which objects, full or update). Every phase of that unattended run writes its own log file into the package's log folder, and that folder is where the actual cause lives, not the workbench screen. ### The build phases and their logs **Body:** A package build runs in roughly this order: spec merge (pulling the latest object specs for everything in scope), table conversion (updating table structures and converting existing data for any table definition changes), business function and business view compile, and finally packaging the compiled objects for deployment. Each phase can fail independently, and each writes to its own log. The build log is the top-level summary and the first place to look - it will name the phase that failed. From there, go to the phase-specific log: the table conversion log for TC failures, or the compile log for business function and business view compile failures. **Code:** ; typical deployment server package share layout \\deploymentserver\B9\PackageName\ log\buildlog.txt log\tablecnvlog.txt log\compileerrors.log obj\ (compiled objects for deployment) ### Common root causes **Body:** The most frequent causes are: a table structure change that failed to convert because the table was locked or in use on the target environment, a custom C business function with a compile error (syntax error, missing header, or a broken reference to another BSFN), an OMW project that was never checked in so the build picked up stale specs, and the deployment server simply running out of disk space partway through a Full Package build. Full Packages are far more exposed to all of these at once because they touch every object in the path code, while an Update Package only carries the objects explicitly included, which is why isolating a failure to a single object often points to building a targeted Update Package instead of repeating the Full Package. ### Full vs Update package considerations **Body:** A Full Package is a complete, self-contained set of every compiled object for a path code and is required after major spec-level changes such as an ESU, a tools release upgrade, or a large custom project going in. An Update Package is incremental and only rebuilds and redeploys the objects included in its definition, which builds and deploys far faster and is what most day-to-day fixes and small customizations should use. When troubleshooting a failed build, confirm you are looking at the right kind of package for the situation - retrying a Full Package build repeatedly to fix one broken business function wastes far more deployment server time than isolating that object into a small Update Package first. ## Pitfalls - Reading the workbench status and stopping there instead of opening the actual log files on the deployment server. - Not checking which deployment server or build machine the package actually ran on when more than one exists in the environment. - Retrying a Full Package build repeatedly without isolating the single failing object into a smaller Update Package first. - Forgetting to check deployment server disk space before assuming the failure is a code or data issue. - Assuming a table conversion failure means data corruption, when it is usually a lock, permissions, or a data type mismatch that a custom conversion routine needs to handle. - Not confirming the OMW project was checked in and transferred to the target path code before the build ran, leaving the build working from stale specs. ## Ai Angle ERPray, Netray's grounded Q&A layer, can be pointed at a package's build log and table conversion log and summarize which phase failed and which object caused it, instead of a CNC admin opening three separate log files by hand across an RDP session. It still needs file access to the deployment server share - it is reading the same logs a person would, just faster and without missing a line. ## Faq ### Why does a package build fail on one deployment server but not another? **Answer:** Server-specific disk space, a stale local copy of specs, or a path code pointing to a different data source can all cause this. Confirm both deployment servers have current specs and enough free space, and check whether the build machine assigned to the package definition is the one you expect. ### Does a failed table conversion mean I lost data? **Answer:** Not by itself. A failed table conversion generally means the conversion did not complete, most often because the table was locked or a data type mismatch needed custom conversion logic. Check the table conversion log for the specific error before assuming any data was altered or lost. ### How do I know if I need a Full Package or an Update Package? **Answer:** Full Packages are needed after ESUs, tools release upgrades, or broad spec-level changes across many objects. For a small fix or a single customization, an Update Package that only includes the affected objects builds and deploys far faster and is usually the right choice. ### Can I see package build progress from the HTML client instead of RDP-ing to the server? **Answer:** Package Build Workbench shows status and history from the client, but the detailed logs live as files on the deployment server itself. Most CNC teams still need file share or remote access to that server to read buildlog.txt and the table conversion or compile logs directly. ## Search terms JDE package build failed, JD Edwards package build log, EnterpriseOne table conversion error, JDE deployment server package build, package build buildlog.txt, JDE full package vs update package, EnterpriseOne compile errors log, JD Edwards CNC package deployment, package build workbench status, JDE package build disk space error --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json