08-08-2008 8:50 AM
Create three programs as mentioned:
REPORT zforms.
*&---------------------------------------------------------------------*
*& Form form_fs_assign
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
FORM form_fs_assign.
FIELD-SYMBOLS <fs> TYPE table.
DATA: fs_itab LIKE STANDARD TABLE OF tab_matnr WITH HEADER LINE.
break-point.
ASSIGN ('(ZPROGRAM1)ITAB[]') TO <fs>.
IF sy-subrc EQ 0.
fs_itab[] = <fs>[].
LOOP AT fs_itab.
WRITE / fs_itab-matnr.
ENDLOOP.
ELSE.
Write:/ sy-repid, 'field-symbol not assigned'.
ENDIF.
ENDFORM. "form_fs_assign
*----
REPORT zprogram1.
DATA: itab LIKE STANDARD TABLE OF tab_matnr WITH HEADER LINE.
itab-matnr = '1111'.
APPEND itab.
itab-matnr = '2222'.
APPEND itab.
WRITE:/ sy-repid.
PERFORM form_fs_assign IN PROGRAM zforms.
SUBMIT zprogram2.
*----
REPORT zprogram2.
break-point.
*-- enter (ZPROGRAM1)ITAB[] in the variable and press enter
* the yellow icon stating that it doesn't exist appears
* but when the following form is called, it does checks
* the <fs> assign and doesnt gives any runtime error
* while in Pricing routine, the similar situation
* does gives the error
PERFORM form_fs_assign IN PROGRAM zforms.
*----
*Execute zprogram1 and debug, works fine..*
*Execute zprogram2, (ZPROGRAM1)ITAB[] doesn't exist, still it doesn't leads to short dump*
*BUT, a very similar situation in a Pricing Requirment Routine leads to a short dump:*
*Runtime Error GETWA_NOT_ASSIGNED*
*ShrtText Field symbol has not yet been assigned.*
*Pricing Routine Code Snippet:*
*-- {3. -
determine qualifying prior invoices in memory----
*
FIELD-SYMBOLS: <fs_vbrk> TYPE table.
FIELD-SYMBOLS: <fs_vbpa> TYPE table.
FIELD-SYMBOLS: <fs_komv> TYPE table.
DATA g_it_vbrk LIKE STANDARD TABLE OF vbrkvb WITH HEADER LINE.
DATA g_it_vbpa LIKE STANDARD TABLE OF vbpavb WITH HEADER LINE.
DATA g_it_komv LIKE STANDARD TABLE OF konv WITH HEADER LINE.
DATA: l_vbrk_lines TYPE i.
ASSIGN ('(SAPLV60A)XVBRK[]') TO <fs_vbrk>. <- "Error occurs here
ASSIGN ('(SAPLV60A)XVBPA[]') TO <fs_vbpa>.
ASSIGN ('(SAPLV60A)XKOMV[]') TO <fs_komv>.
g_it_vbrk[] = <fs_vbrk>.
g_it_vbpa[] = <fs_vbpa>.
g_it_komv[] = <fs_komv>.
DESCRIBE TABLE g_it_vbrk LINES l_vbrk_lines.
READ TABLE g_it_vbrk INDEX l_vbrk_lines.
** remember to make vkorg and vtweg check for vbrk invoices
DELETE g_it_vbrk WHERE vbeln = g_it_vbrk-vbeln.
DELETE g_it_vbpa WHERE vbeln = g_it_vbrk-vbeln OR parvw <> 'WE'.
DELETE g_it_komv WHERE knumv = g_it_vbrk-vbeln OR kschl <> 'ZF02' OR kbetr = 0.
08-09-2008 5:55 AM
Hi Aabhas,
Have a look at note 721297. This might resolve the issue.
It looks like incomplete customising
or ...
Then download the Short dump and create a help message with SAP and attach the Short dump.
Also...
Look at Note 862548 - GETWA_NOT_ASSIGNED Dump in cvse_customizing.
I got this from this thread...
search
http://service.sap.com/notes on the specific package file.
Mohinder
08-11-2008 9:07 AM
You don't get this dump when an assign fails. You only get it when you try to access an unassigned field-symbol. Try this code, and tell me if the problem goes away.
FIELD-SYMBOLS: <fs_vbrk> TYPE table.
FIELD-SYMBOLS: <fs_vbpa> TYPE table.
FIELD-SYMBOLS: <fs_komv> TYPE table.
DATA g_it_vbrk LIKE STANDARD TABLE OF vbrkvb WITH HEADER LINE.
DATA g_it_vbpa LIKE STANDARD TABLE OF vbpavb WITH HEADER LINE.
DATA g_it_komv LIKE STANDARD TABLE OF konv WITH HEADER LINE.
DATA: l_vbrk_lines TYPE i.
ASSIGN ('(SAPLV60A)XVBRK[]') TO <fs_vbrk>. <- "Error occurs here
ASSIGN ('(SAPLV60A)XVBPA[]') TO <fs_vbpa>.
ASSIGN ('(SAPLV60A)XKOMV[]') TO <fs_komv>.
* Add this code block
IF <fs_vbrk> IS NOT ASSIGNED OR <fs_vbpa> IS NOT ASSIGNED OR <fs_komv> IS NOT ASSIGNED.
EXIT.
ENDIF.
g_it_vbrk[] = <fs_vbrk>.
g_it_vbpa[] = <fs_vbpa>.
g_it_komv[] = <fs_komv>.
...
08-11-2008 4:29 PM
Thanks for the reply Matthew.
I have tried the checks u mentioned, in fact i tried both the possible checks,,,
IF <fs_vbrk> IS NOT ASSIGNED.
EXIT.
ENDIF.
and
IF sy-subrc NE 0.
EXIT.
ENDIF.
As mentioned, the error occurs in the ASSIGN statement:
ASSIGN ('(SAPLV60A)XVBRK[]') TO <fs_vbrk>. <- "Run-time error occurs here
IF <fs_vbrk> IS NOT ASSIGNED.
EXIT.
ENDIF
It doesn't goes to the IF statement, the short dump occurs just before it.
Ref thread:
SD-Pricing Routines - Invoice Split - Field Symbols Issue]
for actual scenario...
Thanks...
08-11-2008 4:39 PM
Not sure why you are getting a dump when assigning, it should simply set SY-SUBRC to 4. Anyway, you might want to try this instead, and see if the ASSIGN is successful.
FIELD-SYMBOLS: <fs_vbrk> TYPE table.
data: Lv_itabname type string.
lv_itabname = '(SAPLV60A)XVBRK[]'.
ASSIGN (lv_itabname) TO <fs_vbrk>.
Regards,
Rich Heilman
08-11-2008 6:29 PM
hmm. Very odd. I'll be interested in knowing what the answer is, but I can't think of anything else to try.
matt
08-11-2008 5:30 PM
XVBRK is not declared globally in the program SAPLV60A, which is a function group V60A.
XVBRK is part of the TABLES parameters of the FM inside this function group. and I don't think we can access to the Function modules' parameter by ASSIGNING to the field symbol. This would work fine if XVBRK would have been global table (declared in LV60ATOP).
I think you have to think on different way, instead of trying to access the parameter of FM.
Regards,
Naimesh Patel
08-12-2008 1:42 AM
XVBRK is not declared globally in the program SAPLV60A, which is a function group V60A.
´
For globally declared variables or tables you don't need this "dirty assign".
I suppose the coding
ASSIGN ('(SAPLV60A)XVBRK[]') TO <fs_vbrk>. <- "Error occurs here
is on the wrong place.
Edited by: Jürgen Hartwig on Aug 12, 2008 2:44 AM
08-12-2008 1:32 AM
ASSIGN ('(ZPROGRAM1)ITAB[]') TO <fs>.
ZPROGRAM 1 can't work in ZPROGRAM 2
IN program Zprogram1:
PERFORM form_fs_assign IN PROGRAM zforms. NO Error
SUBMIT zprogram2. Error, because your "Pointer" to point on "Zprogram1"
You know? Your assign so called in Germany "dirty assign"
Edited by: Jürgen Hartwig on Aug 12, 2008 2:38 AM
08-12-2008 3:16 AM
Hello friends,
Rich,
The piece of code you suggested didn't work, and still led to the short dump.
Naimesh,
I agree that XVBRK is not declared globally, and if it is a Table, and declared as global work area using Tables, we could have used it directly using ASSIGN (VBRK)...
But, since its not the case, I am not able to do so...
Still, my requirement remains the same. I have to get the invoices created (in memory) but not saved during a collective billing run.
And the required data is available in the (SAPLV60A)XVBRK internal table, from which I am able to retrieve it for the first time, but clicking on the conditions tab in the item details leads to this short dump, becs (SAPLV60A)XVBRK[] isn't available at that moment. Still, if it is not available I suppose it should just set the sy-subrc to 4 instead of ending into a short-dump.
Jürgen Hartwig,
I know ZPROGRAM 1 can't work in ZPROGRAM 2, but it doesnt leads to the short dump either, does it? But in case of pricing it gives the run time error, this is exception I want to handle!
XVBRK is not declared globally, but since SAPLV60A calls a perform in SAPLV61A, it remains in the ABAP stack and we can access it using (SAPLV60A)XVBRK[] kind of assignment.
When the same is called during Item Conditions display, its PBO is in the stack but not other forms (in which it might have defined).
Rich, is there a way to get all the variables available in scope at any instance during runtime?
Well, Jürgen, I though it Germany it was called "schmutzig zuweisen" :-)... by the way, the same method has been used at several places in standard SAP programs with the sy-subrc check.
Reference Data:
when the assignment happens successfully, the ABAP Stack looks similar to:
Call | Program | Subroutine
10 | SAPLV61A | some_subrountine
09 | SAPLV61A | some_subrountine
08 | SAPLV61A | some_subrountine
07 | SAPLV60A | some_subrountine
06 | SAPLV60A | some_subrountine
05 | SAPLV60A | some_subrountine
04 | SAPLV60A | some_subrountine
03 | SAPLV60A | some_subrountine
02 | SAPLV60A | some_XKOMV_AUBE..subrountine
01 | SAPLV60A | PAI_some_subrountine
when the assignment doesnt happens, the ABAP Stack looks similar to:
04 | SAPLV61A | some_subrountine
03 | SAPLV61A | some_subrountine
02 | SAPLV61A | some_subrountine
01 | SAPLV60A | PBO_some_subrountine
08-12-2008 3:44 AM
Maybe try LIKE this, it works in my (other) program
....TYPE ANY..... or ANY TABLE ????
CONSTANTS:
c_xlikp(32) TYPE c VALUE '(SAPMV50A)XLIKP',
c_xlips(32) TYPE c VALUE '(SAPMV50A)XLIPS[]'.
FIELD-SYMBOLS:
TYPE ANY, "Structure
TYPE ANY TABLE. "Table
ASSIGN (c_xlikp) TO .
Edited by: Jürgen Hartwig on Aug 12, 2008 4:44 AM
Text formatting
Edited by: Jürgen Hartwig on Aug 12, 2008 4:46 AM
08-12-2008 4:38 AM
I tried it Jürgen with no luck... same run-time error!
I guess the problem is not with the TYPE becs it works fine on the first shot, the problem is with the existance of the data in scope... Should there be any means by which we could have checked the existance, the error could have been handled...
I guess SAP work debugger has that mechanism to know if a variable exists or not... like it shows the status using yellow icon stating that the variable doesn't exists when we put it in the variable list.
In classical debugger the structure ABDBG contains this sort of data... but its an structure not the table...
Well, I guess I m going to deep into ABAP, while problem lies at the higher level itself...
By the way I have a solution to my problem of avoiding the dump, but that will be worst of the coding... still it will work fine! And that solution is cheking the system variable:
SY-DYNGR = 'LIST' means the first screen
SY-DYNGR = 'ITEM' means the item screen (where assignment gives the error)
By writing the following code:
IF SY-DYNGR = 'LIST'.
"Assign field-symbols here
ENDIF.
I can avoid the run-time error... but this will be more dirty code... I can use several other system variables as well...
Reference Data:
__System variable__|______Value when no error____|_____Value when error occurs_____
-
-
SYCALLD_________|___X______________________|___X__________________________
SYDYNNR________|___102_____________________|___6002_______________________
SYDYNGR________|___LIST____________________|___ITEM_______________________
SYPFKEY________|___SM_____________________|___TPKO_______________________
SYUCOMM_______|___________________________|___PFKO_______________________
SYTITLE__________|___Create Billing Document___|___Invoice_(F2) Create: Item Data____
SYCPROG________|___SAPMV60A_____________|___SAPMV60A___________________
SYXPROG________|___SAPCNVE______________|___SAPCNVE____________________
SYMSGID________|___KM_____________________|________________________________
SYMSGTY________|___E______________________|___E____________________________
SYMSGNO________|___452____________________|___452__________________________
SYMSGV1_________|___PGLA_________________|___PGLA_________________________
08-12-2008 5:36 AM
Do you exactly try this with using STRING or CONSTANTS????
data: Lv_itabname type string.
lv_itabname = '(SAPLV60A)XVBRK[]'.
ASSIGN (lv_itabname) TO <fs_vbrk>.
or this....
CONSTANTS:
c_xlips(32) TYPE c VALUE '(SAPMV50A)XLIPS[]'.
<fs_xlips> TYPE ANY TABLE. "Table
ASSIGN (c_xlips) TO <fs_xlips>.
Maybe this "direct-assign" doesn't work???
ASSIGN ('(SAPLV60A)XVBRK[]') TO <fs_vbrk>. <- "Error occurs here
Edited by: Jürgen Hartwig on Aug 12, 2008 6:37 AM
Edited by: Jürgen Hartwig on Aug 12, 2008 6:38 AM
08-12-2008 6:14 AM
Jürgen... no luck even this time! I tried with constant, with string and with a beer too 😜 it didn't work!
How about finding a way to get all the variables available in scope at any instance during runtime?
As the debugger has that mechanism to know if a variable exists or not.
It shows the status using yellow icon stating that the variable doesn't exists when we put it in the variable list.
regards,
Aabhas K Vishnoi
08-25-2008 9:08 AM
Problem solved!!
Solution: Delete the statements which cause problems
Well, a workaround worked...
I used the exit in RV60AFZZ to Export the internal tables XVBRK, XVBPA and XKOMV using the EXPORT ... TO MEMORY ID 'XXXXX' command, and imported the same in my routine using the IMPORT ... FROM MEMORY ID 'XXXXX'.
It worked well, I thought of implementing this earlier... but... all laziness!
Still, the question remains in place, why ABAP leads to the short-dump!!
Regards,
Aabhas K Vishnoi
03-24-2016 5:53 PM
This is a very old thread, but I just solved a similar issue. Some of my explanation has been discussed already, but I will recap anyway. The problem, in my case, was that the object I was trying to assign was recognized but just did not exist at that moment. If you put a stop point and run your debugger, look at the ABAP stack (“Desktop 2” while in the debugger). When the program you are trying to refer back to (i.e. SAPLV60A) is not in that list, you will not be able to assign your field symbol. Now you are thinking that I am overstating the obvious at this point, but stay with me. Add the object to your variables in the “Desktop 1” …don’t forget to include the brackets “(SAPLV60A)”. If the object is not in your ABAP stack, the value will be blank and the status column should be either a squiggly line “Invalid Variable” or a bell “Not Assigned”. If the object is invalided, the assign command will simply return a sy-subrc value of 0 and continue, however, if the object is not assigned, the program will dump at the assign statement. Therefore you can simply check that the object exists in the ABAP stack before the assignment of the field symbol. Try something like this:
field-symbols: <fs> type vbrkvb.
data fld1(15) type c value '(SAPLV60A)XVBRK'.
data lt_callstack type abap_callstack.
data la_callstack type abap_callstack_line.
call function 'SYSTEM_CALLSTACK'
exporting max_level = 0
importing callstack = lt_callstack.
read table lt_callstack into la_callstack with key mainprogram = 'SAPMV60A'.
if sy-subrc = 0.
assign (fld1) to <fs>.
else.
exit.
endif.