ESU Merged Code Headaches

dschlieder

Well Known Member
Anyone out there have any good solutions for cleaning up the code that is flagged as "// Following ER merged in B733 upgrade" after applying an ESU?

I just spent the better part of a day re-applying our custom modifications to P4210. We did a merge the last two times we applied an ESU as it is easier and faster and less prone to error to retrofit custom code that was merged then to attempt to type it in.

I have very detailed documentation of our modifications and using that as a guide, I located all of our custom code that was commented out at the bottom of the ER, copied and pasted it where I needed it, verified it and then deleted all of the merged code at the bottom of those sections. (I have found you need to carefully do this. Selecting too much or from the top to the bottom or ??? when you press the little cute trashcan, Form Designer crashes with a memory error. So you need to save and save often and know exactaly where you where the last time you saved. But P4210 doesn't save very fast.)

However, in redoing my documentation for the next go around, I found a number of sections that we did not have any custom code in them that had "// Following ER merged in B733 upgrade" and hundreds of lines of ER after that comment. In some cases, the merged commented code was in there twice, once from the previous ESU and once from the current one we applied.

So I decided to clean that up as it takes too long to check this application in and transfer it to other environments as it is and hoped this would make it easier for those tasks.

So off I went deleting code. All was well till I got to one hyper item. There were a number of commented out but orphaned END IFs and END WHILEs in that area. When I deleted a commented out end if, the first ACTIVE if in the ER was deleted! Then I couldn't save because there was an orphaned active END IF for the IF that was deleted! And of course the code was toast at that point as it deleted code it should not have.

So I deleted nothing but comments and variable assignments, etc. leaving the commented out orphaned END IFs and END WHILEs alone. Good, now I could save the ER. BUT when I went to save the application the validation failed on other UNRELATED parts of the ER! So that wasn't going to work.

Now I am concerned that the code I did delete where we had our custom modifications MAY have done something flaky to the code in those sections. I have no idea what active code above the "// Following ER merged in B733 upgrade" line may have been deleted when I was deleting code below that line.

I have also seen many times in the past where what you see in the ER is not what is actually being executed. I have seen code that appears as "If x = 1", but bringing up the if editor, it will actually be executing "If x = 2"! I started an issue with that one but I don't think JDE believe me.

Any thoughts anyone?

Thanks,

Dave

B7332 SP 15 with some one offs AS/400
 

Larry_Jones

Legendary Poster
Dave,

my thought (shared by a few others) is to avoid these issues altogether by not using the flaky spec merge process.

if you've documented as well as you say (outside of OW) then its proved less time-consuming for me to re-apply my changes from my documentation to non-merged (clean) code, then to chase exactly the kind of problems you're running into. At the very least I sleep better at night :0)

Historically the spec merge process has been problem prone.

Regarding ESUs check out the thread called "JDE Development Cycle" in the archives and take a look at AltQuark's white paper on the subject. Basically the concept is to not take all of an ESU - only the fixes you need.

FWIW,

Larry Jones
ljones@wagstaff.com
OneWorld XE, SP 15.1
HPUX 11, Oracle SE 8.1.6
Mfg, Distribution, Financials
 

Jack_Crouch

Well Known Member
I would also take the time to learn and play around with Visual Compare.
This can really cut down on the re-application of modifications because you
can copy your ER over from the old module to the new.





AS400 V4R5, XE+XU1+18ESUs, SP14.2, NT-SQL7 for CO
 

DBohner-(db)

Legendary Poster
As many of you are aware, I have been trying to narrow down this process, too.

Based on some JDE Documents that have been forwarded my way – we are adhering to the following JDE recommendations.

Here is a table of what can/should happen in respect to Objects and ESUs…

Object Activity Result Comment
Custom Table Added New Table Preserved
Custom Table Change Event Rules Preserved
Custom Table Modifications to Custom Tables Preserved
OW Table Add Column Lost/Replaced
OW Table Change/Modify Column Lost/Replaced
OW Table Delete Column Lost/Replaced
OW Table Add Index Preserved
OW Table Delete Index Lost/Replaced
OW Table Change Index Lost/Replaced
OW Table Change Event Rules Lost/Replaced

OW BSVW Delete Column(s) Lost/Replaced
OW BSVW Delete Tables Lost/Replaced
OW BSVW Delete/Modify Joins Lost/Replaced

OW APPL Add Form Lost/Replaced
OW APPL Add Form Control, Grid Control, Menu/Toolbar Exits Preserved
OW APPL Change/Modify existing form properties, options Preserved Not always preserved…
OW APPL Change/Modify Form Control properties, text, options, overrides and filters Preserved Not always preserved…
OW APPL Hide Controls Preserved
OW APPL Delete Existing Form Lost/ Replaced DO NOT Delete OW FORMS
OW APPL Delete Form Control Preserved DO NOT Delete OW Form Controls
OW APPL Modify Tab Sequence Preserved

OW UBE Add New Control(s) Preserved
OW UBE Add New Section Lost/Replaced
OW UBE Change/Modify Controls, Text, Properties, Overrides, Fonts, Colors Lost/Replaced
OW UBE Move Control location within Section Preserved
OW UBE Hide Control(s) Preserved
OW UBE Delete Control(s) Lost/Replace/Preserved DO NOT DELETE Variables or ER Controls.

Custom Event Rules Add ER to Event in APPL/UBE with no previous ER Preserved
Custom Event Rules Add ER to Event in APPL/UBE with existing ER Changed ALL Custom ER in this event will be disabled and placed at the bottom of the Event
Custom Event Rules Modify ER to Event in APPL/UBE Changed Will be treated as Custom ER
Custom Event Rules Delete Existing ER Changed

OW Data Structures Any Modifications Lost/Replaced

OW Business Functions Any Modifications Lost/Replaced



Based on the above JDE Policy, my recommendations are as follows;
· Attempt to make ER modifications at the Bottom of any Event Section. The Code is going to be disabled and tossed to the bottom, anyway – why not build it at the bottom so it can quickly be re-enabled?
· Don’t Modify OW Tables. Create TAG files with the same keys as the tagged file – add the tag file to necessary views
· It is OK to add Columns and/or tables to BSVWs
· It is OK to add controls to Applications
· It is OK to add controls to UBEs
· It is not OK to remove controls from APPLs
· It is not OK to remove controls from UBEs
· It is not OK to remove columns from BSVWs
Always comment prior to the modded section – providing MOD, Developer, Date and reason. Follow the mod, IMMEDIATELY, with similar information.



Daniel Bohner
drbohner@existinglight.net
www.existinglight.net
JDE - XE & AS/400
JDE - B7331 & MS SQL 7x
 
Discover how to build no-code data integrations and business process automations.

Zoltan_Gyimesi

Legendary Poster
Re: RE: ESU Merged Code Headaches

Hi Dave,
As Jack Crouch mentioned Visual ER Compare is a fine tool. Using it you can apply ESU on one Path Code (e.g. DEV) after that using VERC comparing the ESUd APPL/UBE with the prior ESU version under an other Path Code (e.g. PROD, CRP). You can easily identify the differences and move your custom variables, ER codes. Of course, after you have made it, you have to verify them in FDA/RDA and correct them if necessary.

Visual ER Compare first appeared under XE but JDE rolled back it to B7332 as "ESU Enhancment and Visual ER Compare". Have you applied it already on your system? If not, then you can find documentations about it on the Knowledge Garden. Unfortunately I can not now to point it for you but I am sure somebody else on the List/Forum will can navigate you to it.

Regards,
Zoltán

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

Zoltan_Gyimesi

Legendary Poster
Hi Dave & Daniel,

Daniel, great reply.
I just would like to add some minor hints.

Always keep the following order:
0.) Re-apply DD changes
1.) Re-apply TBLE changes (Generate if necessary. Take care, TBLE generation will dropp your data (requires a complicated procedure), index generation is will not.)
2.) Re-apply BSVW changes. Generate it.
3.) Re-apply PO changes
4.) Re-add your custom variables (take care for the different scopes!). Try to re-add them in the same order as they were added originally and take care for the exact ER Names. (A printer ER list can Help you as well in the order as well to Copy/Paste the ER names of he variables). Save & Close FDA/RDA.
5.) Re-apply your Controls in FDA and your Report Variables in RDA (take care for all of the properties of that and for the corect names.). Save & Close FDA/RDA.
6.) Re-apply added/modified ERs.

If you move from one workstation to an other in this process then you have to move the changes to the other workstation (Check-In/Out and/or Pack Build and Deploy).

Hints for re-appling ER changes.
1.) Open the prior ESU version.
2.) Copy the code parts to the clipboard and save them into a file using ClipBoard Viewer.
3.) Open the post ESU version in the designer. Open the clp files of the ER and paste it into the appropriate place.

Always double-click all pasted ER and verify them, correct them when necessary.
Good habit to re-map all Table I/O, BSFN call and Form/Report interconnects.

About Orphaned If/Endif, While/EndWhile:
1.) Copy the If/While to the clipboard
2.) Copy it somewhere out of the scope of the orphaned.
3.) Delete the orphaned.
4.) Drag the If/While and their End part to the appropriate place.

Yes, there are several situation when the code in ER is diferent from which you see when open the statement with doubl-click. There could be two reason of it.
1.) OW lose or shift the connection between the name and the object (variable, control, etc.)
2.) The object (section, form, variable, control, data structure member, etc.) had been renamed and you see the "maiden name" in the ER list.

Thats all for now.

Good luck ad patience,
Zoltán



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

dschlieder

Well Known Member
Re: RE: ESU Merged Code Headaches

Zoltan,

Thanks for the info (and every one else for that matter).

We have not applied the enhancement for the Visual ER Compare tool yet. So I will print these messages and use that as leverage to get them to do so! We have the ESU but there has been some resistance to change as we are somewhat stable for the moment (first time in almost 2 years we can say that!).

I managed to rid most of the commented code that was moved to the bottom of the ER. I found out that if you select the last line, then select the first line of commented out code, you can delete the block in one step without the form designer crashing. Do it from the top to the bottom and it will almost always crash!

There were only 2 places that I could not delete the code without it effecting the good code but that was only a few lines so it was insignificant.

Thanks again!

Dave
 
Top