Client package on new installation keeps failing

[Ritchie_]

We're currently testing to see if we can move our ERP8 installation to newer hardware, new OS (2008), new DB (sql2008) and new Visual studio (2005 sp1) as we also take SP24 now.
we're coming from an Windows 2003 installation with SQL server 2000 on sp23 something with c++ 6
we're now testing windows 2008 with sql server 2008 and Sp 24 as well as Visual studio 2005 sp1

Now when we build a full package on the Deployment server but the client package fails during the Busbuild part. It gathers the info correctly, creates the MAK files but on building the things like cconvert or any other dll's it keeps coming back with:
\\DPLSRVRNAME\B7334\PD7334\package\PD1712CL\work\jdertdll.c(1) : fatal error C1083: Cannot open precompiled header file: 'jde.pch': No such file or directory

B8900900.c
lots more of these messages and then
LINK : fatal error LNK1181: cannot open input file '\\NLDATAAP72\B7334\PD7334\package\PD1712CL\lib32\sCCONVER.lib'

As far as we can see and check all things should point to correct paths.
Did check the system variables manually by copying the individual paths into windows explorer to see if the path actually exists and all are valid.
Same for the setting in the JDE.ini. all paths open in windows explorer and therefore do exist.

did repair the installation of VS2005 and also completely uninstalled it and installed it again.
When entering cl.exe
also Installed a newer Sp24
Still no result for the client package.

The Server package runs okay. It does build everything correctly (only has a problem with 5 Bsfn's but that is something else, Dlls build okay)

Also on both enterprise and deployment server when opening a cmd box and entering cl.exe it does find the CL.exe
does any one have any idea?

 

[wadie]

There are many reasons why you could get this error. One of the things that solved it for me in the past is this:
mspdb80.dll should not exist in the VC/bin directory of your compiler installation.

Other than that, if your variables have correct paths and SP1 is installed, you should be good to go

 

[higgs312]

I also had the same issue. I had to copy the following dll's from VS8DIR\Common7\IDE to VS8DIR\VC\Bin :
msobj80.dll
mspdb80.dll
mspdbcore.dll
mspdbsrv.exe

 

[higgs312]

If that doesn't help, try this:
The VB2005 Runtime Library may need to be installed on the client. You can do that by downloading vcredist_x86 directly on the client machine to install the Visual RTL. This file can be downloaded from Microsoft website:
http://www.microsoft.com/downloads/details.aspx?familyid=766a6af7-ec73-40ff-b072-9112bab119c2&displaylang=en

 

[Ritchie_]

no luck with these suggestions

 

[klwong]

Most of the documents on Oracle support talk about this issue in regards to Server Package builds. The only one that really talks about problems with the client half of the build is this one (Oracle Doc ID 885281.1).

Basically, it says to make sure the Environment Variables for LIBS, INCLUDES, and PATH are correctly set to the right directories, and that there are ";" separating each value. Then restart JDE, before trying the build again.

 

[Ritchie_]

Checked those things already like twenty times or so. Paths seem to be right as when I copy them part for part from the system env. variables into windows explorer they all come up in the correct directories.
JDE.ini has the same correct paths (checked it the same way as Above)
Uninstalled and re installed VS2005 5 times already.

No luck so far.

Got finally a full client package from the client machine (after copying several files on the Depl.srvr from system\includev to system\include

Now still from the dpl srvr
Will be checking some additional stuff on monday like the registry...

 

[snowman]

Richard,

Did you ever find a solutions for this issue with the jde.pch?

Greg

 

[Ritchie_]

Had not checked this post for a while as we finally made it work

Think what we did was to shorten the install path of VS 2005 to
C:\MS Visual Studio 8
instead of
C:\Program Files (x86)\Microsoft Visual Studio 8

think that did the trick.
That is the same path we used for the real install (as at first it was only a POC) which went fine from the first run.