Results 1 to 4 of 4

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

  1. #1

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

    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:

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


    \\VM-E1-DEPLOY01\E920\DV920\package\DV121818T\include\f56a dp25.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

  2. #2
    Senior Member Larry_Jones's Avatar
    Join Date
    Nov 2000
    Location
    Spokane, WA, USA
    Posts
    3,229
    Jonathan,

    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?
    Larry Jones
    E1 9.2 - TR 9.2.2.6 on Win 2016 R2. SQL Server 2016
    Wintel, BI Publisher

  3. #3
    Member
    Join Date
    Mar 2002
    Location
    Minneapolis, MN
    Posts
    778
    Jonathan,
    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.
    Jeremy
    E1 Consultant
    Minneapolis, MN

  4. #4
    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.

    Thanks,

    Jonathan Theriot

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
The legal restrictions and terms of use applicable to this site are available here.
Use of this site signifies your agreement to the terms of use.
JDELIST is NOT affiliated with JD Edwards® & Company, Oracle or Peoplesoft. Contents of this site are neither endorsed nor approved by JD Edwards® & Company and, or Oracle.