jtheriot
Member
Hello,
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:
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.
Thanks,
Jonathan Theriot
E1 9.2 TR/AR
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.
Thanks,
Jonathan Theriot
E1 9.2 TR/AR