UDC Delete Value

After researching JDElist and Customer Connection I haven't found any information on ways of doing this process without creating a mess. I have been working with JDE for 8 years and understand the down stream impact of doing this, but was wondering how others are handling this. In the past I have gone out and checked to see if a UDC had been used and if not simply deleted it. If it had been used I have SQLed the UDC value on the record to the new value. Unfortunately I am now dragged into a single large UDC change. Thousands of records and thousands of values. I had recommended just adding a DNU (Do Not Use) in front of the Description, but end users will still have to search through all the records so that option has been tossed. Does anyone know of any future enhancements JDE is planning in this area? How have others gone around this? Our IS dept is looking to customize the UDC process, but thought I would check with the List Guru's.

Thanks!

Can you please explain moreyour query?

'Can you please explain moreyour query?'



The query depends on the UDC used that needs to be changed and the table/s that holds the actual value needing to be changed. The requested changes this time are to complex and are over multiple tables so my usual work around will not work.

Our IS dept is looking to add cutomization to where only certain values will appear in the Visual Assist screen for certain users. I don't want to keep adding customization to E1 as we all know how fun that is during upgrades. Just looking for a new avenue to try and make this happen with current functionality or seeing if anyone knows of future enhacements in this area.

Oregon Guy,

Firstly, I hope I understand your situation correctly.

That is an interesting problem - we do much as you suggest - replace the description of the UDC with "do not use" or "obsolete". We do not have a large number of these for any one UDC type, so we don't have your problem.

One option you may consider is using row security on the UDC description and not allowing access if it is "do not use" or what ever value you choose.

Changing the values in the large number of tables that hold UDC values is a huge and dangerous task and there will probably be no garantee that you have changed all that need changing. To do this you will need a cross reference table with the old and new vales and the UDC type. You will need to be able to indentify the tables/columns to change. The JDE database holds information to identify these where the link is defined in the data dictionary. So - theoretically at least - this is possible via program of some sort - unlikely a JDE UBE. However those tables/columns where the link is programmed in the event rules of an application or UBE would not be identified and thus not changed.

I hope this has been of some help.

Thanks for the reply peterbruce!

Never thought of that approach. I've never worked with the security piece in JDE so I'm not clear how it works. Would it be possible to populate a value in the UDC Special Handling (SPHD) and then only let certain sercurity roles access it? Do you have a couple screen shots of the set up? Or is there any Threads out there how to do this? Our IS group is still pretty green on JDE so any materials would be helpful.

Thanks!

Oregon Guy

Oregon Guy,

It would be possible to populate a value in the UDC Special Handling (SPHD) and then only let certain sercurity roles access it, via Row Security.

JDEList has an execellent search facility. You could use it to search the site for "row security".

I would also recommend looking at the manuals. Please read Managing Row Security in the Security Administration Guide For Tools 8.96 Page 69 (page 91 if viewing the PDF in Adobe Reader). Oracle has provided the documentation on-line. Here are some links:

Security Administration Guide For Tools 8.96

Tools 8.96 Guides Index

Current JDE Documentation Index

Archive JDE Documentation Index

Oracle Documentation Index

I would recommend that, if possible, test this thoroughly before putting it into production. Ideally this would be tested in a separate installation of JDE as the security covers all environments/pathcodes in an installation. You could also set up a separate role and user to test. Alternatively separate security can be set up with in the one installation - not recommended, if there is no other option (we have done this - in our dev/test installation).

This is great information!! I'll review these documents with our CNC to get this moving. This approach is going to make a lot of people smile since there won't be customization involved.

If you're ever in Oregon, stop by and I'll throw a few extra shrimps on the barbie!! Thanks again for your help!