Update Package Build on the Deployment-Server. Why not?

Hi,
We use ERP 8.0 for several years and EO 8.10 for one year.
An advisor said we should build all our Update-Packages on a Fat Client, and all Full-Packages on the Deployment-Server.I can´t remember,so the question now comes again: Why should we do this so?
I have already build some update Packages on the Deployment-Server and there were no problems...
Another question: How can i search for Versions in the DEP-Environment on the deployment-server?Change the Mappings?

Thanks in advance
Regards
Jan

Jan,

I believe in the keep it simple procedure, I build all of my packages on the deployment server. If it is a full package, I build it from the DEP7333 environment. If it is an update package, I log in to the pathcode and build it from there. Either way, I build from the deployment server.

Gregg Larkin
Praxair North American CNC

It is my understanding the issue is not with the build but with the assembly of the package. Versions do not exist on the deployment server. So, to include specific versions for an update package you must assemble the update package on a FAT client. After you assemble the package, you can do the actual build on the deployment server.

Hello Jan,
Did he say "build" or "assemble"?
I assemble and define updated packages using a fat client. YOu can see all custom versions there.

Alex

I assemble the update package on the Fat client. I build it from the
deployment server. On a Full package I do it all from the deployment server in the
Dep env.
Barb Kramarski

Hm, Thanks for your answers
Is there any way to assembly Update-Packages with Versions in the DEP-Environment?

Hi,

the main issue with building assembling / building update packages is that the sysetm would enquire on the F983051 table for the environment that you are logged into to find the version information. So if you are building assembling / building a package for PD and are logged into DV it will enquire on Versions - DV and not Versions - PD which is what you would want. So being logged into DEP you would be looking at Versions - Local instead of the correct versions datasource for your build.

The other issue that used to crop up at times when building update packages on the deployment server was the fact that the last part of the build process within the R9621 was to copy the dll's / specs / etc back up to the pathcode level on the deployment server. This would sometimes fail if you were logged into the environment that you were building the update package for on the deployment server, as you would be locking some spec / bsfn files (as you were using them being logged into that pathcode).

That is why JDE always recommended that you build update packages on a fat client (developer client) logged into the environment that you are building for.

The story changes slightly for full packages in that they used to recommend that you build FULL packages in the DEP environment on the deployment server. This was because the logic worked in a slightly different way as far as versions were concerned as you were building for all versions so it automatically picked up the versions datasource for the build environment. Also again because of the updating the pathcode last issue you could not be logged into the environment you were building for on the deployment server. You could always still use a fat client (developer client) but the amount of time that the package build took and the tresources from that PC meant that the PC was effectively useless for anything else for 6 - 8 hours.

As usual...Sr. Larkin is absolutely correct. Packages should always be built on the deployment server, as that is it's purpose and reason you had to buy it. And fulls can be assembled and built from DEP, any updates should be assembled in the environment you are building for, then built on the deployment server.

Can't tell you how many locations I've gone into where they say that they build on a fat client because they had "issues" on the deployment server...say WHA?!!? But no...I must remember they are my client...goos frabba, goos frabba, serenity now, serenity now...