Data Dictionary Changes for QTYINV

Hi everybody,

We need to convert the decimals of the DD Class QTYINV from 0 to 2 on our Xe Installation. We are already on Live, and we would try this changement on one 'test' environment before deploying it to PD7333. Our idea is to create one 'copy' of DD, make the 'test' env point to it, modify de display decimals and then test all programs. If always is OK eliminate the DD copied and deploy the changement everywhere.

Someone knows the 'better' way to do this without any risk?
I thought to copy DDtables (i.e. F9200 --> F9200C) change the OCM of test env to point to these new tables, set the decimals to 2 on copied tables and then test.
Can someone confirm that this way could work?

Thanks for any kind of help

Bye

Fabrizio

oof

I presume theres data in "QTYINV" all over the shop - yes ?

This is going to be messy, no matter what you do. When you make the change to the F92* tables, don't forget to regenerate your DDDICT spec files AND your GLBLTBL files. On your enterprise server, you're going to have to stop services and delete these spec files in the pathcode you want to test.

I'd say that you'll probably be seeing some data issues. You'll at least have to multiply everything by 100 to get the data looking right again. Best not to make this change when theres data in the system - after all, there are probably other values in the database linked to QTYINV and maybe data structures out in the code also linked.

Hi Fabrizio,

If I were you, I'd test the data dictionary change on a
sandbox environment (separate Deployment and Enterprise
servers, isolated from your "real" servers).

Thanks for your answer to my big problem.

Effectively QTYINV is the reason, and my client needs to change decimals with data in tables

The solution I think to propose is to create another DD, copy of the existing one, create one datasource pointing to it (DataDictionary - XX7333) and modify ocm for the environment XX7333 to make it point to the new Datasource. This temporarly, if the tests are OK I'll restore the original DD. Do you think I need to regenerate DDDICT even if I leave standard tables' names?

Many Thanks

Fabrizio

Hi Sebastian,

this is a really good idea, but unluckily I don't think my client would consider it (problems of money and time). But I agree with you, it is the best solution to assure integrity without any risk.

actually JDETips had a few good issues on this (wake up Andy...).

I've used part of it in my own scripts and it works just fine. The actual process is pretty easy. Just run the cross reference to see everywhere these items are used. The n find out which columns actually have data. Then just write one big script to move decimal places, update your DD, regen the dddict and ddtext and voila (okay perhaps I made it sound a bit to easy).

Colin

[ QUOTE ]
Do you think I need to regenerate DDDICT even if I leave standard tables' names?

[/ QUOTE ]

Yes. Data Dictionary will not look any different otherwise - you need to regenerate DDDICT, DDTEXT and GLBLTBL pretty much everywhere - stop and restart services as well, since the data dictionary is also cached in memory.

I agree. You are playing with fire when you make a change to this particular DD item. I could be wrong, but would you not have to convert the data that is already stored so that the column data will display the new DD value correctly? Sometimes you can also get around your issue by creating a new UOM that will resolve your decimals for you...but this is a case by case situation.

Back to the decimal positioning. Your old data is going to be stored differently than any new data that comes in after the DD change......Am I right on this???

I hope you have a good backup strategy in place. They may find out that buying a server to act as a Sandbox will be a heck of alot cheaper in the long run...especially if you corrupt your data.