DD Change

What are the draw backs of chaging data dictionary item QUED from 5 numeric 2 decimals to 6 numeric and 2 decimals?

Has anyone attempted this? I imagine I will have to re-compile all files touched.

Jimmy

JAB
OW XE
AS/400 (Enterprise)
WinNT (Deployment)
SP16

It took me a few seconds to get it but the 'jde_x_pert' thing is a nice
touch, wish I though or it.

Anyways you'll have to do the following:

1. Change the Data Item
2. Deploy the change to any FAT clients - delete global tables and data
dictionay specs
3. Deploy the change to TSE/WEB/JAVA clients - rebuild global tables and
data dictionary specs

Since you're only widening the length of the data item I don't think you'll
need to do any table updates. You may have some forms or reports that are
not properly formatted.

I'd run the Cross Reference for just this data item to see what tables,
forms and UBE's will be affected.


Colin

Colin Dawes, MSc
City of Guelph
B733.2 SP16, Oracle 8.1.6.3.4, FAT & TSE

Hi,

It seems that I'm a member of your mail list.
Thanks for your helpful message.

However, I don't want to receive your mail any longer.
Can you remove my e-mail address from you mailing list?

Thanks a lot.

Regards.

Re: RE: DD Change

Colin,
Have you ever done this before? I have a couple scenerio's that are haunting me. This field is usually used in a calculation and if JDE uses a variable of 5 numeric and 2 decimal to help with the calculation, wouldn't this be a problem.

Also, I believe I would have to change the data dictionary items, delete global and dd specs, but wouldn't I have to re-generate all files this alias touches in all environment for it to notice 6 numeric and not 5 numberic.



JAB
OW XE
AS/400 (Enterprise)
WinNT (Deployment)
SP16

RE: RE: DD Change

Colin,

I have to uphold the concerns of Mr. X. Changing the decimal settings of an
existing JDE DD Item - can have lasting results. If you need a field with
specific definition, it would be best to create it. If the newly created
field needs to exist within a table, create a tag file and add that tag file
(fully keyed) to the necessary views.

Unless you really know every table, app, whatever ... that the DD is used in
- and are willing to work on all of them - it is a frightening thing you are
planning.

Mr. X is right. Halloween is over, you should keep the haunting as such.



Daniel Bohner
[email protected]
www.existinglight.net
JDE - XE & AS/400
JDE - B7331 & MS SQL 7x

Re: RE: DD Change

Hi Jab,

I do not know where and how is used QUED but generally it is not recommended to change an existing and used data item, mainly its type and length.

About calculation:
As far as I know, OW handles Math Numeric values in the Event Rules with the widest format, with the maximum absolute value and maximum precision (decimals). The length and display decimals of the data item takes effect only when it is written:
* to a control an a Form in an APPL
* to a Report Variable on a Section in an UBE
* to a field in a database table

I do not recommend you to change the size of QUED, it could cause several problems.

If you share with us why do you want to do it then maybe can figure out alternative solution(s) with a little help of the Forum.

Have you post this issue to the Developers Forum too? (I haven't visited it today.)

Regards,
Zoltán

B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)

Re: RE: DD Change

I have posted this on the developers side too.

The problem is QUED hours deals with manufacturing and outside processes. We have Qued hours that are larger that 999.99 hours so they would like to increase the size to 9999.99.

Has anyone ran into the problem, If so what is a good fix? They do not want to split the operation step into too, which would make the most sense.

Would it be more suffice to change the dd item to 5 with 1 decimal?





JAB
OW XE
AS/400 (Enterprise)
WinNT (Deployment)
SP16

RE: RE: DD Change

I've changed many data items in JDEdwards but I've never actually increased
the length of a data item. If this value is used in a calculation then
OneWorld should just use the data dictionary specification. Of all the
possible data dictionary changes this ones seems like the easiest and most
straight forward.

Just in case you're wondering I routinly change the row and column
descriptions, defaults, next numbering and associated UDC for data
dictionary items.

Colin

Re: RE: RE: DD Change

Thanks to everyone's input on this strange situation.

I have talked upper mgmt out of the change.


JAB
OW XE
AS/400 (Enterprise)
WinNT (Deployment)
SP16

RE: RE: DD Change

Any data dictionary change to the field/decimal length is questionable to
say the least. I have only done changes in data decimals when it has been
deemed absolutely necessary, with the detailed document from JDE, and made
sure it was completely and very thoroughly tested before it went anywhere.
We first tested it on a Fat client and then put it into use. We still
aren't LIVE so it's still being tested as it goes through all of the testing
steps here... I wouldn't know why anyone would change a length in a
field... a new data item should be used in that case... Otherwise I too
only make changes in row/field descriptions... and they have to be fully
documented also.

Happy Friday!!!

Lori
OW Xe SP16 Update 2
AS400 V4R5
NT
Citrix
email: [email protected]

Re: RE: DD Change

You would be much better off trying to change the data dictionary item from 2 decimal places to 1 then to try to actually try to change the field size. I would never recommend changing the field size in a JDE file. If you did make the change you would have to test it pretty thoroughly. My guess is you would also have to change the display decimals on the move hours and you may even have to look at the business function that does back-scheduling to make sure there aren't other data dictionary items you need to modify. You don't mention exactly how much queue time you need. Perhaps you can also add a value to the move time from the previous operation or the operation following the outside operation to increase the ' effective queue time' That would allow you 2000 hours of queue time which in most cases is sufficient.

CSMS,MFG,DIST
OneWorld