cancel
Showing results for 
Search instead for 
Did you mean: 

Unbelievable ABAP oddity - SapScript related

Former Member
0 Kudos

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

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Thanks for the suggestions all. This is not your typical ABAP bug. It is so odd that I decided to make a screen capture video of it. If you are interested in watching the debug session to see for your own eyes then please download the movie here:

[www.daydots.com\downloads\sapforum_destco.zip|www.daydots.com\downloads\sapforum_destco.avi]

~63Mb AVI

or

[www.daydots.com\downloads\sapforum_destco.zip|www.daydots.com\downloads\sapforum_destco.zip]

~33Mb (zipped)

This was created by Camtasia by Techsmith. if you need a codec to play it please look here:

[http://www.techsmith.com/download/codecs.asp|http://www.techsmith.com/download/codecs.asp]

Thanks everyone for your interest in helping out. I think if you watch the video you'll catch on to how odd this is. In the first round I send

+DESTCO+

to the form. What does the form print? ++ That's it, just ++. Very odd.

Crew

Former Member
0 Kudos

hello,

you must consider that your exit ZXSADU01 is also called (again)

during sapscript command /: ADDRESS....

and I think address_number is empty during this command..

reagrds, darek

Former Member
0 Kudos

Ok. That's an interesting thought Darek. A previous post mentioned checking the ST05, which I did, but I don't think I took into account that the user-exit is called a second time simply because I was never able to debug through it. Apparently the print occurs in an update task and I seem to be having trouble getting a debug session in those cases.

Let me take a second look at ST05 to watch for the double ADRC SELECT and see if I can validate this hypothesis. If the first call to the UE has and address number (the call I can see) and the second call does not have the address number (the call I can't see) that could explain it.

Thanks! I'm off to test some more.

Crew

matt
Active Contributor
0 Kudos

Shifted to the Form Printing forum - you might get more specialised help there. To debug in the update task, you need to change the settings while in the debugger. When the update task gets launched, you get another debug screen opening.

matt

Edited by: Matt on Apr 17, 2009 4:24 PM

Former Member
0 Kudos

hi Crew,

try to correct your sapscript:

/: 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&

/: ADDRESSNUMBER = &VBDKR-ADRNR_WE&

/: ENDADDRESS

regards,darek

Answers (3)

Answers (3)

Former Member
0 Kudos

Darek,

That was it. I modified the UE to place a timestamp value in NAME1. I recorded that value and then compared it to what came out on the printout. Sure enough the timestamps do not match which means that your assertion about a second call (one that I cannot yet debug) was spot on. Rob's suggestion of using ST05 would have hinted at this as well as possibly some other suggestions that were made but I wasn't taking into account the possibility of a second (silent) call to that UE.

Is it possible to debug an ABAP UE called from a SapScript form even if it runs in an update task?

Now that I know what is occurring I can set to repairing it. Thanks so much to all and esp. you and Rob for the quick help and excellent suggestions. I will post the points.

Crew

Former Member
0 Kudos

Hi,

If possible can you please paste the code that selects the name from ADRC and moving it to

VBDKR-NAME1_WE

Also as mentioned by Rob...Put a watch point for the variable VBDKR-NAME1_WE and check where it is getting cleared..

Thanks

Naren

Former Member
0 Kudos

Have you run ST05 to see that the value is actually being retrieved correctly?

Rob

Former Member
0 Kudos

No but I have debugged through the SELECT ... INTO and found that the incoming variable called HOLD_NAME1 = 'ALTERNATE COMPANY'. I create a new variable called WA_NAME1 and set it eqaul to a literal value of 'ALTERNATE COMPANY'. I compare the two visually and they are the same. I compare the hex values of both varaibles and they are the same. I use an IF HOLD_NAME1 = WA_NAME1 test and they are the same. Yet, one prints and the other does not. I am confounded.

Thanks,

Crew

former_member156446
Active Contributor
0 Kudos

Do you think, using standard text help ? to print the address...

Former Member
0 Kudos

Unfortunately no. Theses are customer addresses that change from invoice to invoice.

Thanks for the thought though.

Crew

Former Member
0 Kudos

Well, it looks to me that it is not getting the value from the database. I'd run ST05 to at least disprove this.

Rob

former_member156446
Active Contributor
0 Kudos

I create a new variable called WA_NAME1 and set it eqaul to a literal value of 'ALTERNATE COMPANY'. I compare the two visually and they are the same.

did you change the value in the layout.... &WA_NAME1& in se51

Former Member
0 Kudos

hi,

this address is printed in sapscript window thru text-element

(/E txt) or without ? and this NAME1 is not initalized/or overwritten

regards,darek

Former Member
0 Kudos

Rob: I'm checking ST05 now but the ABAP debugger does show that the SELECT against ADRC does populate the field as expected.

J@Y: The field that actually goes to the form is now &WA_NAME1&. I just poke the value into that variable as a literal and then set the form's variable = WA_NAME1.

I've tried all of the std. stuff. This one is just way odd.

Former Member
0 Kudos

>

> Rob: I'm checking ST05 now but the ABAP debugger does show that the SELECT against ADRC does populate the field as expected.

>

> J@Y: The field that actually goes to the form is now &WA_NAME1&. I just poke the value into that variable as a literal and then set the form's variable = WA_NAME1.

>

> I've tried all of the std. stuff. This one is just way odd.

So, can you put a watch point on the variable to see where it gets populated and gets cleared out?

Rob

Former Member
0 Kudos

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

Former Member
0 Kudos

did you try to print value before command address:

example:

  • &VBDKR-NAME1_WE&

/: 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

if nothing will be printed then variable is filled for example to late...

regards,darek