jdelist
Guest
ONE OF MY CUSTOMER ASK CHANGE A DD DECIMAL FROM 2 TO 4( CTS1) . I WAS VERY PUZZLE. Can I do it? How about table f4801 which use this dd?
How can i do it?
How can i do it?
Alex_Pastuhov
Legendary Poster
The application in OneWorld that changes DD does not modify the actual data
to reflect this change, so it will have to be done manually (through a
script) to all columns based on that item throughout the database after the
DD has been changed...
It is usually done by JDEdwards consultants - just get JDE to do it for
you...
Regards,
Alexander Pastuhov
Senior Technology Consultant
J.D. Edwards Australia
465 Auburn Road, Hawthorn, Victoria, Australia
Office: (03) 9823-5111 Fax: (03) 9824-8193
Mobile: 0408-363-524
E-mail: [email protected]
to reflect this change, so it will have to be done manually (through a
script) to all columns based on that item throughout the database after the
DD has been changed...
It is usually done by JDEdwards consultants - just get JDE to do it for
you...
Regards,
Alexander Pastuhov
Senior Technology Consultant
J.D. Edwards Australia
465 Auburn Road, Hawthorn, Victoria, Australia
Office: (03) 9823-5111 Fax: (03) 9824-8193
Mobile: 0408-363-524
E-mail: [email protected]
ljorgensen12
Member
Hi,
basically, there no problem with changing a the dispaly decimals field of a
data dictionary because what the display decimals field is doing is
controlling the decimals comma. The client that I work for have changed all
the cost fields from 4 to 6 decimals and we have not discovered any problems
with that change. However, one of the things that you have to take into
consideration, is whether somebody has hard-code the decimal places but a
good test of the modification will reveal that. Your concern about, what
will happen to your table. Notthing will happen because the decimal places
are not stored on the table, but controlled by the data dictionary of the
corresponding field in the table. However, the one thing that you should not
do is extending the length of the field because the length is hard-coded in
every data structure where the field is used.
Hope this could help.
Lars Jorgensen
XE, SP15.1, AS/400
basically, there no problem with changing a the dispaly decimals field of a
data dictionary because what the display decimals field is doing is
controlling the decimals comma. The client that I work for have changed all
the cost fields from 4 to 6 decimals and we have not discovered any problems
with that change. However, one of the things that you have to take into
consideration, is whether somebody has hard-code the decimal places but a
good test of the modification will reveal that. Your concern about, what
will happen to your table. Notthing will happen because the decimal places
are not stored on the table, but controlled by the data dictionary of the
corresponding field in the table. However, the one thing that you should not
do is extending the length of the field because the length is hard-coded in
every data structure where the field is used.
Hope this could help.
Lars Jorgensen
XE, SP15.1, AS/400
David Robertson
Reputable Poster
Hi Lars,
(Did we meet on Holland?)
The value stored in the database does reflect the decimal value. If you have a quantity of 1 and display decimals of 4, then the value stored on the database is 10000. So changing to 6 decimals, the value would then translate as 0.01 unless you update everywhere that the field is used.
This process is best performed at the install stage, before any data is in the files.
If you are doing this further down the line, then you should build the search indices, so that you can search for the tables that the DD element is used in, and update them by whatever means is convenient. An SQL script is probably easiest and quickest, as all of this would have to be done offline.
Testing these sort of changes is difficult as most people are running only one Data Dictionary, so the change will affect all environments at the same time.
Cheers,
David
(Did we meet on Holland?)
The value stored in the database does reflect the decimal value. If you have a quantity of 1 and display decimals of 4, then the value stored on the database is 10000. So changing to 6 decimals, the value would then translate as 0.01 unless you update everywhere that the field is used.
This process is best performed at the install stage, before any data is in the files.
If you are doing this further down the line, then you should build the search indices, so that you can search for the tables that the DD element is used in, and update them by whatever means is convenient. An SQL script is probably easiest and quickest, as all of this would have to be done offline.
Testing these sort of changes is difficult as most people are running only one Data Dictionary, so the change will affect all environments at the same time.
Cheers,
David
ljorgensen12
Member
Hi David,
yeah, you are absolutely right. I forgot to mention that when you change the
Display Decimal field you need to update all the tables that contains that
field by a factor corresponding to your change in decimals. Well, and that
is the tricky part, if the cross refs. do not work you do not know which
tables to up-date. However, when a new Data Convertion runs the fields will
then be filled with the correct formatted data. David, I have not worked on
a project in Holland, so you must be confusing me with someone else.
many Greetings
Lars Jorgensen
XE, SP15.1 AS/400
yeah, you are absolutely right. I forgot to mention that when you change the
Display Decimal field you need to update all the tables that contains that
field by a factor corresponding to your change in decimals. Well, and that
is the tricky part, if the cross refs. do not work you do not know which
tables to up-date. However, when a new Data Convertion runs the fields will
then be filled with the correct formatted data. David, I have not worked on
a project in Holland, so you must be confusing me with someone else.
many Greetings
Lars Jorgensen
XE, SP15.1 AS/400
Solack
Active Member
Bravo, Well stated.
Hi Lars,
(Did we meet on Holland?)
The value stored in the database does reflect the decimal value. If you have a quantity of 1 and display decimals of 4, then the value stored on the database is 10000. So changing to 6 decimals, the value would then translate as 0.01 unless you update everywhere that the field is used.
This process is best performed at the install stage, before any data is in the files.
If you are doing this further down the line, then you should build the search indices, so that you can search for the tables that the DD element is used in, and update them by whatever means is convenient. An SQL script is probably easiest and quickest, as all of this would have to be done offline.
Testing these sort of changes is difficult as most people are running only one Data Dictionary, so the change will affect all environments at the same time.
Cheers,
David
--------------------------
Visit the forum to view this thread at:
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=&Board=OWDEV&Number=15948
Hi Lars,
(Did we meet on Holland?)
The value stored in the database does reflect the decimal value. If you have a quantity of 1 and display decimals of 4, then the value stored on the database is 10000. So changing to 6 decimals, the value would then translate as 0.01 unless you update everywhere that the field is used.
This process is best performed at the install stage, before any data is in the files.
If you are doing this further down the line, then you should build the search indices, so that you can search for the tables that the DD element is used in, and update them by whatever means is convenient. An SQL script is probably easiest and quickest, as all of this would have to be done offline.
Testing these sort of changes is difficult as most people are running only one Data Dictionary, so the change will affect all environments at the same time.
Cheers,
David
--------------------------
Visit the forum to view this thread at:
http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=&Board=OWDEV&Number=15948
Zoltan_Gyimesi
Legendary Poster
Just an addition to the other replies.
Do not forget to build full client and server packages for ALL Path Codes and deploy them to all running locations (clients and servers) or at least delete DDDICT, DDTEXT and GLBLTBL spec files let the JITI starting again from scratch (I amn't sure that it works for servers too) after you made your changes and conversions and before anybody use OW again!
Imagine, that clients where the DD hade been JITIed before the change will use the old decimal places while on clients where DD JITIed after the change will use the new one. It could cause serious problem.
Good luck,
Zoltán
B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)
Do not forget to build full client and server packages for ALL Path Codes and deploy them to all running locations (clients and servers) or at least delete DDDICT, DDTEXT and GLBLTBL spec files let the JITI starting again from scratch (I amn't sure that it works for servers too) after you made your changes and conversions and before anybody use OW again!
Imagine, that clients where the DD hade been JITIed before the change will use the old decimal places while on clients where DD JITIed after the change will use the new one. It could cause serious problem.
Good luck,
Zoltán
B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)
Similar threads
- dtujo2022
- JD Edwards® EnterpriseOne Developers
- saumik.gupta
- JD Edwards® EnterpriseOne Developers
