Question about deploying a table change


Reputable Poster
We are on E1 9.0, tools release 8.9.42. I am building and deploying a package to production that includes a table change to a custom table. We have added a few fields to this custom table.

My question is in regards to the table change. From what I've gathered and am also told by oracle/jde, is that when you deploy the package to your production environment, you still have to manually rebuild the table in OMW. So the step s will be to deploy the package to production. Then sign on to a production fat client, and in OMW go into table design aid and choose Generate Table. It seems I would need to first do a get to get the now new table specs for that table onto the fat client. Then generate the table and indexes.

That all makes sense but certainly seems a bit of a manual and quirky process. Is there some other simpler way or is this just the way it has to be done.

It occurred to me, that after deploygin the package to production, I could install that update package on my fat client also. But it seems a quick Advanced get of the table would serve the same purpose and be quicker and safer given I will have a bit of a tight window for deploying and affecting this change.

Any thoughts are appreciated.
WARNING: Before you hit the Generate Table button, you need to realize that this will wipe out any data you have in this table. Maybe you're okay with that, but I thought I'd bring it to your attention.

As for table changes, we usually just end up adding new columns, and if we have data in a table, we'll just use a database tool to add the columns manually, being very careful to create the columns with the exact same data type/size as JDE would use -- especially important if you've converted your business data to Unicode.

So, yes, there are alternatives, but they'll require someone with DBA skills.
You also need to delete the glbtbl spec files on your Enterprise Server after deploying the package. The files are located under your PD900/spec folder on the Enterprise Server.

Depending on your database platform there could be additional steps (clear SQLPKGs on AS400 for example)
Actually thats not a step (deleting specs on server) that I've had to perform when changing a custom table.
You don't say what your back end DB is, but if it is an IBM i (AS/400) you will also need to delete SQL Packages
Its funny this topic should come up today. We deployed a PD package today with a custom table change (added a field to the end). Normally we don't reboot any servers (JAS or Enterprise) after deploying a new package.

Two of our APPLs do a read from this custom table to display additional fields in a grid - a simple F56MYTABLE.Fetch. Well after deploying the package none of the values from the custom table would show in the grid - custom fields were all blank. We could see data in the underlying DB table, including the new field so it was not a data issue. We tried clearing cache on the JAS servers. We tried re-doing the Java Gen on all objects involved including the table and APPL, etc. Nothing worked. Finally we re-booted the JAS servers and suddenly everything worked.

Bottom line is that I have never fully trusted Oracle's "hot deploy" for either the enterprise server or the JAS server and now I am even more skeptical. Anybody else ever seen anything like this?

Yes, this is the exact behavior we see. After deploying a table change, if the JAS instances are not restarted any ER that references the table will not work.

Thanks for the confirmation.

Changing existing tables is not an everyday occurrence and when they do happen I often torture our CNC group by requesting a full build. They usually do these full builds on weekends which also happen to coincide with a normal server reboot so that may be why we have not seen this before.

In JDE, for tables, you have :
- jde specs of the table that are stored in the database (but not used at runtime) and the local specs (on entreprise servers/fat clients) used at runtime. They describe which fields and indexes you used to define your table.
- the database tables, with their fields and indexes and data
- for web, the web specs of tables (stored in F98998 and F98999, at least in Xe …)
The process to deploy change of table is :
1 - update the jde specs of the table stored in the database (by doing the checkin in OMW)
2 - update the local specs on servers and fat clients (deploying a package, update or full. No need to delete any specs tables -dddict, ddtext and glbtbl must be deleted only for
data dictionnary changes-).
At this point, your jde specs are ok, but the table didn't change in your database.
3 - You have to make the «real» table in the database match the jde specs … Otherwise, you'll get error messages (when jde will try to access data in fields existing in jde specs but not defined in the database).
You can achieve that by either :
a - generate the table, using OMW, on a fat client.
To do that be sure the local specs of your fat client are up-to-date (either you installed the update/full package, or get the spec from OMW).
Beware that generate a table from there drop the table in your database and re-create it, according to the jde specs (fields, indexes, …).
So it means it'll delete any data in your table.
If you want to keep data, you'll have to save it first in some other table (in Oracle, with a simple create mysavetable as select * from mytable), then generate in OMW and insert the records back in your new table (chosing what you'll put in the new field for these previous records …).
b - You can make the change directly in your database to have it match with jde spec, either by adding the new columns (in Oracle, alter table mytable add …), which i don't like much (it leads to table fragmentation), or by sql drop/create the table.
The advantage of that 2nd option is that it can be done in a script to automate the deployment …
I use the first method only for totally new table, because you can generate the database table at any time before the deployment, because it won't be used before the deployment is finished. No error to be afraid of.
I use the second one for existing table with new columns that have to be changed only during the deployment and can't be before.

4 - on Xe at least, you have to use the egenerator to update the web specs of your table. It will use the local spec of your generator to update the F98999x tables.
Before doing it, i usually run R98CRTGL ube on the egenator, after i installed the update package. Because deploying an update package with a table delete the global tables, and makes the
client do JITI, which can sometimes disturb egeneration process.
5 - Bounce jas services, to be sure there's no old specs in jas cache.
Anyway, for our production environment, deployment is always done with restart. Hot deploy works fine on developpement platform, where not too much activity, but in production, too much problem.
Thanks all. The deploy was successful, no issues. The process was as follows.

1. Our dba backed up the table.
2. We deployed the JDE package.
3. From a production fat client, I went into OMW and generated the table and indexes.
4. The table was now empty. The dba then inserted the data from the saved table back into the table.
5. I actually forgot to clear those other recommended tables, but as mentioned above that was not really needed.
Hi All,

I haven't done this in a while. Here is what I've done in DEV.

1. Create a backup for current Worktable.
2. Add column at the end of the table.
3. Do a Table build.
4. Copy data back in.
5. Create\Deploy DEV package with newly added column to worktable.

Couldn't I do the same for PROD? This would happen on a weekend when we do our PROD update builds.

Thank you,
Hi All,

I haven't done this in a while. Here is what I've done in DEV.

1. Create a backup for current Worktable.
2. Add column at the end of the table.
3. Do a Table build.
4. Copy data back in.
5. Create\Deploy DEV package with newly added column to worktable.

Couldn't I do the same for PROD? This would happen on a weekend when we do our PROD update builds.

Thank you,
The build isn't enough, you need to generate the table in the target pathcode. Everything else is correct.
I do the following:
1. Add the column at the end of the table.
2. deploy table.
3. create a table backup.
4. regenerate the table.
5. copy data from backup.
6. (drop backup table).

if you create table backup before modify column or deploying, not problem.

it's recommendable restart all web and enterprise services (I always do it when deploying)