Unbelievable ABAP oddity - SapScript related

Question

Sappers,
I have officially come across the oddest ABAP problem that I have seen in 8 years.  I've spent 8+ hours trying every possible code variation to get around it but nothing works.
Here's the story in summary.
We have an invoice with shipping fields NAME1, NAME2, NAME3, and NAME4.  Under certain circumstances we need NAME1 to use a different field.
Our user-exit has worked perfectly since 2000 and is now acting odd after an upgrade to ERP6. 
If I print a specific invoice, I get (using example data)
COMPANY NAME
123 STREET ADDRESS
CITY NAME  ST  99999-0000
In the user exit the field NAME1 = 'COMPANY NAME'.  I need it to say 'ALTERNATE COMPANY NAME' which resides in table ADRC.  No problem, I pull that data into a variable and then overlay want is in the NAME1 var with what it in the ALT_NAME1 var so that NAME1 now says 'ALTERNATE COMPANY'.  Great, no problems.
Here's the weird part.  I don't expect you to believe me right off but please understand that I have gone through literally 50+ iterations to find out how to get around this behavior.
Printing the invoice ...  I get.
123 STREET ADDRESS
CITY NAME  ST  99999-0000
Whoops.  Where did ALTERNATE COMPANY go?  Let's try setting NAME1 to a hard-coded value like 'XXXXXXXXXX'.
Printing the invoice ...  I get.
XXXXXXXXXXX
123 STREET ADDRESS
CITY NAME  ST  99999-0000
Ok, we know the data element is getting through so why is the value 'ALTERNATE COMPANY' not making it to the form?  Let's try this...
Rather than use the value of 'ALTERNATE COMPANY' that came in from ADRC instead I hard code NAME1 = 'ALTERNATE COMPANY'.  A literal.
Printing the invoice ...  I get.
ALTERNATE COMPANY
123 STREET ADDRESS
CITY NAME  ST  99999-0000
What the?!  It prints the value when I hard code the value but not when the same value comes from the database?  True.  I have tried every manner of manipulation on the NAME1 variable with no change in the behavior.
Here's a really odd behavior.
CONCATENATE 'X' NAME1 'Y' INTO NAME1.
At this point NAME1's value is 'XALTERNATE COMPANYY'.
Printing the invoice ...  I get ... believe it ...
XY
123 STREET ADDRESS
CITY NAME  ST  99999-0000
If I compare the value 'ALTERNATE COMPANY' that came from ADRC against a varaible with the literal 'ALTERNATE COMPANY' they are the same length and the hex codes are exactly the same as they should be.  How in the name of all that is pure and good can ABAP print XY when the variable contains 'XALTERNATE COMPANYY'  ?!  Is this some kind of cruel unicode joke?
<< Removed >>
Thanks all,
Crew
Edited by: Rob Burbank on Apr 16, 2009 2:59 PM

Answer 1

My SapScript experience is not deep so I'm just going to show you the code from the invoice form.
/*  ENDIF.                                                         
/:  ADDRESS DELIVERY PARAGRAPH ZD                                  
/*    TITLE    &VBDKR-ANRED_WE&                                    
/:    NAME     &VBDKR-NAME1_WE&, &VBDKR-NAME2_WE&, &VBDKR-NAME3_WE&,
/:    STREET   &VBDKR-STRAS_WE&                                    
/:    POSTCODE &VBDKR-PSTLZ_WE&                                    
/:    CITY     &VBDKR-ORT01_WE&, &VBDKR-ORT02_WE&                  
/:    REGION   &VBDKR-REGIO_WE&                                    
/:    COUNTRY  &VBDKR-LAND1_WE&                                    
/:    FROMCOUNTRY &VBDKR-SLAND&                                    
/:  ENDADDRESS                                                     
The variables I'm working with in the user-exit are eventually dumped into some print program's VBDKR structure.  &VBDKR-NAME1_WE& is the field that I am affecting from the user-exit.  I have full control of that field from the user exit as descibed in my post.  If I poke in 'XXX' then 'XXX' makes it to &VBDKR-NAME1_WE& and prints.  If I poke in the value that came from a database (verfied to be present) then &VBDKR-NAME1_WE& prints nothing.  See my comment about concatenating a literal to the front and back of the database value.  Only the literals X and Y print from that whole string.  Something is definitely amiss.
Thanks,
Crew