Problems when Building update packages

Hi all, I'm recently having troubles to get update packages built on PD. As soon as I sendf it to build it luachs the ube R9621 and it does nothing. I had to kill oexplore.exe to have it running again. I think is due to a non-natural object created by ouy Development department. However I am able to build update package with only natural objects (ie R98OWSECA) but no with modified objects. The JDEDEBUG.LOG shows nothing but the JDE.LOG shos this message 'Unable to specifications for table F90704'

My set is Xe 7333 upd 7 with SP23, all running on Win2k3 and MSSQL Server 2000.

Hope anyone can help.

The "unable to find F90704" message is normal for Xe on SP23. If you want to see what is going on with the package build, look at your Deployment Server, in your B7333 share, in the path code directory, in the Package subdirectory, and in the package name's subdiretory. Read through the file ClientPkgBuild.log.

This will tell you more about what's going on than the JDE.LOG.

HI klwong, i have seached that file and maybe you meant Builderror.log which I'm pasting here, the fact that only the packages with natural objects are built properly make me think that maybe our dev guys made something wrong that cause this corruption. I also tried rebuilding and old package (one I built 2 weeks ago) and fails. My only way out as I see is send the packs to build from my computer.

any suggestion?
Thanks for answer.

Does the object compile in PY7333? Have you done a full package in PY7333? Have you done a full package in PD7333? If it compiles in PY7333 but not PD7333, then have the developer demote the object. verify that it is good, and then repromote. I would recommend a full PD package. Look at the hot thread of the day, "allowed activities during full package build" for the pros of building a full instead of an update package.

Yes, that's the right file. Sorry, I was looking at my E812 server, and I forgot that it's a different file in other releases.

So, it looks like it finishes building the client update package, and then never gives you the PDF, or launches the R9622 server build?

I hate to impose the time penalty on you, but given that it hangs either during or after it is updating the parent full package specs, you might want to think about building that full PD package as Gregg suggests. I have seen instances where something (virus scanner, some other process) hits at the wrong time, and the parent package specs get corrupted.

Hi Pearljabm

I've seen this before on Xe. A full package build will fix your issue. Your GBRSPEC file on the deployment server in the parent package has become corrupted somehow - maybe another update earlier on has somehow mucked something up. But, yes, you're hanging on updating the GBRSPEC - a VERY fast way to getting it working again is to try and copy a GBRSPEC.DDB/XDB from a client back to the deployment server (after ensuring you backed up the original one) into the parent package directory.

BUT - the safest option is just to launch a full package build.

By the way - I don't want to cause you any scares - but if you're sure that your parent package hasn't been updated recently - you might want to perform a full virus scan....something has affected your parent packages' GBRSPEC.DDB file and you might want to just check the deployment server (after all, it is sharing B7333 to the world !)

Hi and thank you gusy for taking the time for reading and posting some solutions.

You have describen quite well my problem. All the packages are built properly on PY. And all tha packages with only natural objects are completed suceesfully on PD. As AltQuark suggested we had an issue during the build with our virus scanner (Mcafee) so maybe that's why the spec files got corrupted, but how come all the natural objects are packed properly?

However, I don't feel like changing the GBRSPEC.DDB/XDB files since we build a lot of packages weekly so if I copy those files from another cliente they may be out of date. What's the risk of doing so? What if I take a station and install the last full package and then copy the those files to my DEPLOY?

I think it's gonna be a very long week.

Thanks a lot for answering.

Wait! If you're going to copy the files from a client, you should:

1) Install the full package.
2) Install all the update packages attached to that full package.

That way, when you copy the files in, you'll have an up-to-date version of them.

While that may get you over the hump as far as getting update packages built in PD, what happens when you install a new workstation? With this approach, I don't think you'll have confidence that everything is in sync. I think you will ultimately find yourself building that full package anyway.

Noooo......

Your CAB files might be corrupt too. I only posted that as a real last resort in a pinch. Truly, don't copy the GBRSPEC file back to the deployment server (wish I hadn't mentioned that now !!!) - you really really really need to submit a new full package. Had you done that this evening, it would have been ready by the morning !!!

However, you have got me concerned. It SOUNDS like you might have a virus on your deployment server. Get the deployment server checked thoroughly before you do ANYTHING more and be prepared to bring in the backup tapes...

Well, seems I got it solved with a pretty valious help from FMorales. I used this walkaround to be able to build packages because I was in a hurry to deploy some urgent modifications to run a payroll.

I've renamed the folder 'spec' from the parent package end then expanded the files spec1.cab and spec2.cab into a given folder. Then copied it to parent package folder and renamed it as 'spec' and after that my packaes were build they were supposed.

I know this may be just a temporal solution and that's why I'm planning to build a full package next week.

Thanks you all for your support and your comments. It's not gonna be a loooong weekend after all.