Header file not copied to /include - PKG fails

MFreitag

MFreitag

Reputable Poster
Hi all,
we have this issue on our current production environment (9.2.2.6 with E900) that we have to manually copy a custom header file F59xxxxx.h from the pathcode's /include folder to the package's /include folder on dep and ent server once we start the package build. Can be done by script of course, but it's still pretty annoying. When we setup the new environment (9.2.3.3 with E920) for testing first i encountered the same issue and now i really feel like fixing it.
SO reading through MOS there's lots of those errors, mainly on specific header files that can be fixed with a manual edit or an ESU. Since ours is a custom file i had to dig deeper. Found some other scenario about file permissions but they are fine. Then i read something about the header file not being used by any function and is therefore not being copied - but why does the package build fail then?

It's under CCUSTOM and the work/buildlog entry looks like this:
D:\JDEdwards\E920\DV920\package\DVFULL\source\N59xxxxx.c(28): fatal error C1083: Cannot open include file: 'f59xxxxx.h': No such file or directory

Any ideas? :)
 
It's only your PD920 environment? You don't have this issue in PY or DV?
 
I had a similar issue in our lab environment after taking an ESU. The new releases store the function source in a table (I forget if it's configurable) and the package build will pull the source from that table. In our case, the source code in the table was not updated with the change yet the DS pathcode folder was. There is a flag in a path code table that signals the function source is in the database. We had to clear that and run a full package, which re-loads the table with the source code from the path code. Perhaps you are seeing something similar where the table source did not get into the database. Of course, I'm assuming you are setup that way.

Craig
 
A little more on this … the svrpkgbuild.log on the deployment server in the full package directory will explain where it is getting the files from:

Wed Apr 17 08:42:15 - Header structure initialized successfully.
Wed Apr 17 08:42:15 -
Wed Apr 17 08:42:15 - Check where the file repository is located, Deployment Server or Database.
Wed Apr 17 08:42:15 - Source/Include/Res files will be retrieved from the F98780R repository.
Wed Apr 17 08:42:15 - Check is complete, package build will continue.
Wed Apr 17 08:42:15 - Files will be retrieved from Database Repository.

There are several MOS articles about it and how to reset the pathcode flag if things get out of synch.

Craig
 
I actually know about all this already, but for some reason i didn't make that connection, haha!
Yeah there's the F98780R and H tables now, that build the repositories for each pathcode now. It's not configurable, it's by force.

I'll definetly try that but still the main question remains: why do i have to manually fill the whole repository again for just one missing object and why is it not being updated? :rolleyes:
 
You could try sql deleting the object in F98700R and H, then doing a check out / check in in DV920, but being you've had it everwhere...are you sure the records for that custom table aren't borked in Central Objects / F9860/F9861?
 
You could try sql deleting the object in F98700R and H, then doing a check out / check in in DV920, but being you've had it everwhere...are you sure the records for that custom table aren't borked in Central Objects / F9860/F9861?

Hi - why would i find a table (header) in F98700R/H? From my understanding (and having a look at my table) it only contains web objects like E1PAGE, FORMAT etc.
For the central objects, i'm not sure, the table is in there but with a reeeally old timestamp (112nnn), which is weird. IIRC we didn't have this build problem since back then, maybe since two years, but not seven!

Any other ideas more than welcome. I also emailed our developers if they know anything about it...

EDIT:
got it - i guess you just made a typo and meant F98780R/H :)
i'll try deleting it there and see how that goes
 
Last edited:
Whoops, yep, F98780H/R and not the UDO repository tables, sorry. Glad you found it.
 
Am facing the similar issue. Please let me know if it is resolved in your case?
 
Am facing the similar issue. Please let me know if it is resolved in your case?
Phew three years ago but i'm pretty sure that it solved the problem by manually going into F98780R/H and deleting the entries so they get re-inserted.
 
Back
Top