BSFN builds locally, but not during deployment build because of table columns



We received a package from a vendor with some updates in July. It included some BSFNs, files, etc. One of the files already existed, and I'm not sure if the BSFNs did or not. The file in question had an update to the columns, the BSFN in question is referencing these new columns. This was found because when the build attempted to happen we got this:

\\VM-E1-DEPLOY01\E920\DV920\package\DV121818T\source\B5600186.c(103) : error C2039: 'x1ccid' : is not a member of 'F56ADP25'

\\VM-E1-DEPLOY01\E920\DV920\package\DV121818T\include\f56adp25.h(20) : see declaration of 'F56ADP25'

This error repeats for each missing column/reference in the BSFN. There's a few, "Few too arguments" but that I assumed was because it didn't recognize the columns it was trying to use. I pulled down the file and the header (.h) was different, the header had the correct columns, whereas the object from OMW showed the older columns. So I used the existing header file, tweaked the existing table, saved it, then generated it and the header file. Afterwards I checked out the BSFN, built it successfully and checked it back in. I thought this would fix it. Pushed it up, asked the CNC for a build. Same error. The table and the BSFN were in the same project, so we separated them, and promoted the table by itself. That build worked, but the BSFN project failed with the same error. I've had the CNC build the BSFN on their machine that the do deployments from, but not on the DEP machine, do I need to ask him to build it on the DEP machine? I thought that would just build locally, unless they checked it in.

Running out of ideas, with the exception of maybe deleting the BSFNs and the file from JDE, then using the vendor's .par files to start over, fixing the table prior to the first build attempt.

I'd really like to understand why this isn't working though. If the specs for the table are right in DV on both the web and the db server, the BSFN builds locally, the issue was the table columns and that's fixed.


Jonathan Theriot

E1 9.2 TR/AR

if it wasn't hosed before it is now :(
JDE tools tech doesn't use the "display names" for objects and object components behind the scenes. Rather there are unique ID values that act as the object identified and are what is used to link objects/components together. You trying to patch stuff together from different sources kinda disrupted all that.

You're original problem may have just been a bad release / par file from your vendor. Have you contacted them for help?
While the table object is checked-out, do the table header generation (not table gen, but header gen), then check the object back in. If I'm understanding your issue correctly, it sounds like the the f55adp25.h file still corresponds to the older version of the table. Those BSFN errors means the .h file is not representing the newer table format.

To be sure, prior to performing the above steps, you can look at that .h file on the deployment server in the \include folder to see if it corresponds to the newer or older version. I'm betting it's the older and performing those steps should make it current. You can check the file again on the deployment server after check-in to make sure it has the newer fields... if so, a new package build should work.
We've contacted them, and we've decided to scrap all related objects, with their approval. So the BSFN, Report, and Table have all been removed from our system. Thanks Larry, I knew that was true for most everything, was just in repair mode and thought regenning everything would be okay as long as it was done at the same time. We'll have them send over a .par file with those objects if we end up needing them, but for now they seem like they were an extra feature we weren't using anyway as the Table was empty, and the BSFN and the Report were the only thing that referenced that table.


Jonathan Theriot