Table generation error during special instructions

Hi Guys
I have just applied JD18813 ESU to my dev environment and one of the special instruction tell me to generate table F060117A before package build. But whenever I try to generate this table then I get the error message that "Table Generation failed".
JDE.log shows
JDB9900318 - Failed to find table information in TAM using RDB.

I would appreciate any suggestions.

Did you do a Get on the local machine prior to generating the table?

Hi Dan
Thanks for the hint. Initially I did not checked out the table. I just checked out it in the dev environment in the fat client and I was able to generate it.
However the special instruction tell me to do it on deployment server. So which environment should I choose on deployment server???
Also I am just wondering should I check it in( to update the header files on the deployment server after generation) and promote it though OMW when applying it to PY( in addition to generate it in PY environment) to update the header files for PY environment during promotion.

Thanks

I'm not sure why JDE wants you to generate the table from the deployment server. Whenever I generate a table, I do it from DV7333. I just do a get for the table first. But if you do it on the deployment server, use DEP7333. There is no need to check the object in/out. However, you may want to build a small update package for the new table.

Dan
Thanks for your help. I just spoke with JDEdwards support and they told me that since it is a new brand new object so I should check it out in dev and generate and check it in.
It seems that you are doing get( same as checkout but without token).. So do you check it in(you would like to update the header files on the deployment server..not sure how important it is. I always get a lot of missing source files during packge build and JDE support had told me not to worry).
Also wondering do you generate this table in the local planner data source ( It is not planner ESU so I think we do not need to generate)??

With all new objects, I've always generated them in DV7333. All you need to do is a Get to bring the table specs down to the local machine. I like to do a Get instead of checking out/in the object because when you do that, it modifies the merge flag for the object. Which could bite you when you try to upgrade or load another ESU/ASU.

When you applied the ESU, you applied it to DV7333, correct? If so, the specs are already in the CO for DV7333. There's no need to use the deployment server to generate the table. The reason they tell you to generate it on the Deployment server is because the specs are already there from when you installed the ESU/ASU.

JDE is correct, you should still do a package build to get the specs out to all machines and servers.

The JDEPLAN environment should only be used for loading ESUs and ASUs. All of the special instructions should be done in either DEP7333 or the environment that you are loading the ESU or ASU into. More often than not, you will be doing them in the environment that you are loading it into.

I hope this helps!

Dan

Hi Dan
Thank you very much. This is really helpful. I was just wondering that how my merge flags are getting changed by developers. Now it makes sense that they are checking in/out application( even without modifications) that is causing the merge flag to change.
Yes, I applied ESU to development environment. The only question that I have is that if you generate new table in dev path environment on the fat client then it will create the table definition in the database plus it creates the header file in the header directory in the path code on the fat client. This file wil not be copied into the header directory in the development path code on the deployment server if u do not check it in.

Do you manually copy this file to the deployment server or do not worry about it at all??

It's my understanding that when you install/apply the ESU with the new object, all the necessary header files, etc... are installed into the path code directory on the deployment server. Therefore, you wouldn't have to worry about copying the file up to the deployment server.