Skip to Content

SAP Upgrade Conflicts -II

SAP Upgrade Conflicts -II

 In my previous blog (SAP Upgrade Conflicts -1), I stopped writing by finishing 7 points of conflicts I faced. Here I would like to continue with few more conflicts in continuation of previous blog numbering.

 8)      First I will point out one table M_VMVAA. If you ever worked on 3.0 you would have noticed, M_VMVAA is a pooled table.  In 4.5, it is a table view.  In addition, the field BSTNK (Customer PO) has a different field name.  All references to this field must be changed from there on. There lies the conflict. There are several different Match code fields in the View (PO, Customer, Ship To…) which might be used through out in SAP system.  In addition, there may be function modules that reference this table.  In this case, we need to correct the parameters of the function and references in the functions code, save and generate.  Some function modules have SAP includes linked to them.  By saving and generating the changes in the function, the SAP include will also be updated automatically.

 9)      In earlier versions of SAP aggregate functions was able to perform on numeric characters (NUMC). In fact it was working perfectly there. Where as when we entered the Uni-Code world, these lousy rules were avoided.  So  in a select statement, using SUM or AVG options on non-numeric fields now results in compilation error. There need a manual change of using this functions only for numeric fields.

 10)   Do you know, in previous versions of SAP table name, field name and data element names can have same name. For e.g. the system lets you create a table named ‘WERKS‘, if a data element called WERKS already exists. When it comes to the upgrade part, where the table was imported through a transport, table activation fails. Only way is here is to re-create the element. Also the old data element needs to be deleted.

 11)   Similar kind of issue was there with general syntax change. The Non usage of Key-words as variable names. In version 4.6B none of the SAP keywords can be used as variable names otherwise causes syntactical error. SAP Keywords should be treated as reserved words and not to be used in Custom Programs.  :)) I know this conflict might be suprising for few as we are used to the new convention.

 12)    Again in 3.0, the order in which the “OTHERS” statement was placed did not matter for Function Module exceptions. From 4.5 onwards the “OTHERS” exception must be the last exception stated. Initially when I saw, I was surprised, for all my programs I was compelled to do manual changes.  I was forced to re-insert the function module – assumption being the SAP has updated the code.  Naturally this will not work with custom function modules.

 13)   Another interesting thing which I noticed in 4.5<</i> is calling an error message during F4 processing. In 4.5 it is no longer possible to send an error/warning message to the user during F4 processing (At selection screen on value request).  It will result in a short dump. Instead of using an error or warning message, we need to use an information box or a success message (the success message looks exactly like an error message would, but the program won’t short dump).

 14)   The reference TYPE used in custom Function modules should have same prefix as TYPE_POOL. If a FM has a TYPE_POOL as  ZCTM, then the reference type in import/export parameters should have the same prefix (ZCTM_).  For an example, I have a function module ZCTM_MYFUN. Previously (in 3.0) the FM was using types starting with ‘ ZCTM_‘ which belongs to type-pool ‘CTM‘ and with the upgrade the types needed to be changed to ‘ZCTM‘.  However to change the reference types in a FM requires to ‘cancel Release’ the FM.  For this, we need to go to the ‘Administration’ menu item of FM, under ‘Function Module’ menu, click on ‘Release’ and then ‘Cancel Release’.  If you are not the original owner (Person in charge) of the Function group then either the owner should do this task or in debug mode change the owner name to your name and cancel the FM release and SAVE it. After you make the changes to reference types, do the same steps to release the FM. 

 15)   Another nutty thing I noticed in older version is about Program attribute – Status. If status ‘S‘ is used, while using debug, the program will not stop at the breakpoint give error message “Breakpoints in system programs are only observed in system debugging“. When it comes to upgrade we may need to check SE38 Program Attributes => Change program to status ‘K‘ Customer production program.

 16)   This is one of the very common violations you could see from OLD vs NEW.  Usage of “WRITE” Statement is change from 4.6 onwards. Earlier version supported statements like 

               WRITE /10 MY_FIELD.     But needs to be modified like…
               WRITE AT /10MY_FIELD.

 17)   After all 4.5B release SAP has changed the language field from 1 character to 2 characters. Hence while in updated I faced problem with all programs using the language field. In 4.5B, inputting one character value in CAPS does not cause an error.  However, if the value is lower case it does cause an error. I could found two solutions for this. 

      1) If the changes to make the field 2 character are minimal then make the change. 
       2) If the changes are extensive (i.e.  Changes incoming file layouts, Access utility layouts, etc)
         then keep the field as one character and make it mandatory that it value is in CAPS.

18)    In upgrade SAP had made changes to USR03 and SADR tables. The data that was previously stored in USR03 (SAP user) or in SADRP/SADR (office user) was merged in the tables of central address management (ADRP, ADRC, ADCP, ADR2, ADR3 and so on). The programs which are using those tables will not give syntax errors, but will not generate any output. As per the OSS note 96607:

  1. Replace accesses to table USR03 by calling function module SUSR_USER_ADDRESS_READ or BAPI_USER_GET_DETAIL.

2 Replace accesses to the addresses of an SAP application in table SADR by calling function module ADDR_GET.

 19)   Here we go with the common thing in reporting. The CURRENCY / QUANTITY / UNIT. There causes syntax error in 4.6B without proper usage of currency / quantity/ unit masks. Internationalization of SAP restricts the use of currency and quantity fields without proper masks and country specific attributes in version 4.6B. SAP provides the mask in the form of a table field. The table name is TCURC.

 20)   I faced problem with DATA TYPE problems in SELECT statements. For 4.5 onwards, it is no longer possible to SELECT INTO a variable which has an incorrect data type (for example:  Selecting a value of data type DEC INTO a variable declared as type C will result in an error – possibly even a short dump).  Declaring a variable with the correct data type (for example using LIKE) and using this variable in the SELECT statement solved the problem. Immediately after the SELECT statement this variable may then be assigned to a new variable with a different data type.

 21)   Upgrade, I could see selection-screen generation errors. Error happened when generating the selection screen, especially when the screen contains overlapping objects. This may have happened, especially in earlier versions of SAP, the programmer might have created a comment at a precise position etc. after creating a parameter or any such object and this precise positioning might interfere with an existing object at that position. Use the ABAP/4 program RSDBGENA to generate the selection screen of your program – this helps you in more precise analysis of the error. Then make sure that if using the precise positioning of the comment, the objects don’t overlap. To be sure, use a different line to include the comment using the syntax “SELECTION-SCREEN BEGIN OF LINE ….. SELECTION-SCREEN END OF LINE“.

 22)   Select Statement Field Declaration also had issues.  Within a select statement, specifying the field to pull in the table-field name format causes a compile error in 4.5B. Example of code that will produce an error:


 23)    The problem with ABAP/4 query tool. Queries created using the ABAP/4 query tool in earlier versions is not supported in 4.6 B. It requires creating a new Query from 4.6 onwards. Then we could make the necessary changes as the query is version dependent.

 24)   When I saw older version, it was surprising for me to see the usage of internal table in a restricted form (using the additions FROM, LOOP, TO   statements). Those restrictions are replaced by IF… ENDIF in new versions. Also WHERE is also replaced with IF….ENDIF statement.

 25)   I could see another conflict in the system field SY-CPROG. In new versions the data length was changed from 8 to 40. Hence the usage in report header or data definitions (…like SY-CPROG), etc caused issues like field overflows in new versions while upgrading.

  26)   From 4.5 onwards, SAP does not allow selection of fields into target VAR if the length of the table variable and target variable does not match. The issue affects SELECT Statements / CALL FUNCTION interfaces / Programs Using TVARV or generic table fields. The problem occurs only for non-char fields. SELECT LOW into TMP_VAR from TVARV where name = ‘XXXXX’ will result in a Run time Error if the TMP_VAR refers to SY-DATUM or of NUMC/PACKED data type. I just leave the solution for you to find out. Image

 I felt, if I start writing the conflicts, it’s going to be more and more, as SAP systems are getting enhanced in each releases. The new comers to SAP who works in new versions might have not seen or realized was what happening in previous versions of SAP. From ABAP/4 language programming prespective, probably this could be a torch to the older versions.

 As I mentioned earlier, the ABAP violations are more and more, and I agree here there are  a few listed out. In the next posting I thought, I’ll wind up with these keyword conflicts and come up with the set of violations happening with Function Modules. I mean the obsolete one and the new suggested one.

1 Comment
You must be Logged on to comment or reply to a post.